feat(localnet) - add localnet log aggregation tool #4758
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
Frozen
approved these changes
Sep 18, 2024
sophoah
reviewed
Sep 20, 2024
sophoah
reviewed
Sep 20, 2024
sophoah
reviewed
Sep 20, 2024
|
hey @mur-me good job on this. I made a few comments, please address. Additionally, I've managed to run the stack with my localnet ! |
|
hey @GheisMohammadi @Frozen please test the stack, this PR is for you guys |
Addressed all the comments, added a few improvements like restart and anon accces to the grafana |
sophoah
reviewed
Sep 20, 2024
…nymus access - it will directly open explore page now, add log commands to the help
mur-me
force-pushed
the
feature/add_localnet_log_aggregation
branch
from
8adf4b6 to
432dc20
Compare
sophoah
changed the title
sophoah
approved these changes
Sep 24, 2024
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue
I've covered localnet deployment with the same tool set as higher networks - Promtail-Loki-Grafana.
What was done:
debug-start-loganddebug-stop-log,debug-restart-logDetails:
test/logs_aggregator/folder.envfile intest/logs_aggregator/.envtest/logs_aggregator/.envis a source of variables for docker-composetest/logs_aggregator/.envTest
Local run:
working in /home/uladzislau/go/src/github.com/harmony-one/harmony/test/logs_aggregator /home/uladzislau/go/src/github.com/harmony-one/harmony/test/logs_aggregator [INFO] - stopping log aggregation [+] Stopping 3/3 ✔ Container logs_aggregator-loki-1 Stopped 2.6s ✔ Container logs_aggregator-promtail-1 Stopped 0.6s ✔ Container logs_aggregator-grafana-1 Stopped 0.6s Going to remove logs_aggregator-promtail-1, logs_aggregator-grafana-1, logs_aggregator-loki-1 [+] Removing 3/0 ✔ Container logs_aggregator-promtail-1 Removed 0.0s ✔ Container logs_aggregator-grafana-1 Removed 0.0s ✔ Container logs_aggregator-loki-1 Removed 0.0s [INFO] - cleanup .envmake debug-stop-log-aggregator against already stopped/not-started localnet it will be failure
make debug-start-log-aggregator against not-started localnet it will be failure
make debug-restart-log:
Unit Test Coverage
Before:
After:
Test/Run Logs
Operational Checklist
Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)
YES|NO
Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.
Describe how the plan was tested.
How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?
What are the planned flag epoch numbers and their ETAs on Pangaea?
What are the planned flag epoch numbers and their ETAs on mainnet?
Note that this must be enough to cover baking period on Pangaea.
What should node operators know about this planned change?
Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)
YES|NO
Does the existing
node.shcontinue to work with this change?What should node operators know about this change?
Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?
TODO