Bilješka
Pristup ovoj stranici zahtijeva provjeru vjerodostojnosti. Možete pokušati da se prijavite ili promijenite direktorije.
Pristup ovoj stranici zahtijeva provjeru vjerodostojnosti. Možete pokušati promijeniti direktorije.
Eventstream workspace monitoring (preview) has a few known limitations that affect how monitoring data is collected, displayed, and queried.
Important
Eventstream workspace monitoring is currently in preview.
Node status updates are periodic, not real-time
The EventStreamNodeStatus table is updated approximately every six hours. If a node changes status (for example, from Running to Failed), it can take up to six hours for the change to appear in the monitoring table. For immediate status checks, use the Eventstream editor, which shows the current status in real time.
New tables might not appear automatically after enabling monitoring
After you enable workspace monitoring, the Eventstream tables (EventStreamNodeStatus, EventStreamMetrics, EventStreamErrorMetrics) might not appear in the monitoring database right away. If you don't see the tables:
- Go to Workspace settings > Monitoring.
- Turn monitoring off, and then turn it back on.
The tables will appear after the monitoring database is refreshed.
Existing Eventstreams require republishing
Eventstreams that you published before enabling workspace monitoring don't automatically emit monitoring data. You need to republish each existing Eventstream for it to start sending data to the monitoring tables.
Artifact and workspace names might show outdated values
In some cases, artifact and workspace names may not appear correctly in the experience. This can result in either missing (empty) values or names that are no longer up to date. This is a known limitation, and we are actively working on improvements to ensure more accurate and reliable metadata display in future updates.
The ArtifactId and WorkspaceId columns always contain the correct, current identifiers. When writing queries, use ArtifactId and WorkspaceId for reliable filtering instead of names.
Metrics identify underlying services, not individual nodes
The EventStreamMetrics and EventStreamErrorMetrics tables use a CorrelationId column to identify the underlying service resource (such as a processing job or event hub entity) rather than the individual Eventstream node name. In most cases, there's a one-to-one relationship between a CorrelationId and a node. However, when an Eventstream uses advanced processing (such as the SQL operator with multiple destinations), a single CorrelationId might map to multiple nodes. Use the NodeDirection and NodeType columns together with the CorrelationId to distinguish between nodes.
Diagnostic logs aren't yet available
During public preview, the monitoring tables show metrics and error counts, but not detailed diagnostic log messages. This limitation means you can see that errors occurred, but not the specific error messages. Detailed diagnostic logs are planned for a future release.