Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create chain-monitoring.mdx #764

Merged
merged 19 commits into from
Oct 7, 2024
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions pages/builders/chain-operators/tools/_meta.json
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
{
"chain-monitoring": "Chain Monitoring",
"explorer": "Block Explorer"
}
74 changes: 74 additions & 0 deletions pages/builders/chain-operators/tools/chain-monitoring.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,74 @@
---
title: Chain Monitoring Options
lang: en-US
description: Learn the basics of onchain and offchain monitoring options for your OP Stack chain.
---

import { Callout } from 'nextra/components'

# Chain Monitoring Options

This explainer covers the basics of **onchain** and **offchain** monitoring options for your OP Stack chain. Onchain monitoring services allow chain operators to monitor the overall system and onchain events.
Offchain monitoring allows chain operators to monitor the operation and behavior of nodes and other offchain components.

## Onchain Monitoring Services

Onchain monitoring services provide insights into the overall system and helps chain operators track and monitor onchain events. Some examples of onchain monitoring services include `chain-mon` and `dispute-mon`.

### `chain-mon`

description of service + how to enable metrics

### `dispute-mon`

Chain operators should consider running `op-dispute-mon`. It's an incredibly useful securities monitoring service to keep an eye on games, basically giving visibility into all the status of the games for the last 28 days.
Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/grafana/dispute-monitor-1718214549035.json).

## Offchain Component Monitoring

Offchain monitoring allows chain operators to monitor the operation and behavior of nodes and other offchain components. Some of the more common components that you'll likely want to monitor include `op-node`, `op-geth`, `op-proposer`, `op-batcher`, and `op-challenger`.
The general steps for enabling offchain monitoring is pretty consistent for all the OP components:

* Expose the monitoring port by enabling the `-—metrics.enabled` flag
* Use Prometheus to scrape data from the metrics port
* Save the data in `influxdb`
* Share the data with grafana to build your custom dashboard

### `op-node`

`op-node` metrics and monitoring is detailed in the [Node Metrics and Monitoring](/builders/node-operators/management/metrics) guide. To enable metrics, pass the `--metrics.enabled` flag to the op-node. You can customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively.
See [this curated list](/builders/node-operators/management/metrics#important-metrics) for important metrics to track specifically for `op-node`.

### `op-geth`

description of component + how to enable metrics

### `op-proposer`

description of component + how to enable metrics

### `op-batcher`

description of component + how to enable metrics

### `op-challenger`

The `op-challenger` operates as the *honest actor* in the fault dispute system and defends the chain by securing the `OptimismPortal` and ensuring the game always resolves to the correct state of the chain.
For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/protocol/fault-proofs/cannon)). See the [OP-Challenger Explainer](/stack/protocol/fault-proofs/challenger) for more information on this service.

Enable the following metrics flags for `op-challenger`:

```
--metrics.addr value (default: "0.0.0.0") ($OP_CHALLENGER_METRICS_ADDR)
Metrics listening address

--metrics.enabled (default: false) ($OP_CHALLENGER_METRICS_ENABLED)
Enable the metrics server

--metrics.port value (default: 7300) ($OP_CHALLENGER_METRICS_PORT)
Metrics listening port
```

## Next Steps

* If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions).
Loading