Find the message behind a monitoring alert
A website check reports a failure, but a red status alone does not explain why it happened. Application logs may show a failed upstream request, a rejected operation or a configuration problem close to the same time. Central log monitoring puts those messages in a searchable workspace so you can investigate them alongside your measurements.
MetriBeacon provides dedicated log sources, field and text search, live viewing, saved views and log alerts. This guide takes you from one selected source to a focused search and an alert with a useful response. It also explains why an empty result is not automatically evidence that an application is healthy.
What is log monitoring?
Log monitoring means collecting selected messages, preserving useful context and evaluating them for investigation or alerting. A metric answers a numerical question, such as how much memory is in use. A log can describe an individual operation and the information its application recorded.
| Signal | Useful question | Important limit |
|---|---|---|
| Metric | Is response time or resource usage changing? | A value alone may not explain the cause |
| HTTP check | Does the configured request meet its conditions? | It does not reveal every internal application step |
| Log entry | What did the selected source report? | The message is evidence from that source, not proof of every outcome |
| Log alert | Did matching messages reach the configured condition? | Missing collection must be considered separately |
A log message and an incident at the same time give you an investigation lead. They do not by themselves establish causation. Keep the website monitor and server measurements available while examining the corresponding time range.
Connect one log source deliberately
Follow the central log management guide. Sources belong directly to a workspace: you do not need to create a monitor or measurement series just to collect logs.
- Open Logs → Sources → Add source and select the integration.
- Choose the server, application or project whose logs you want.
- Select the required logs, review the settings and choose Connect.
- Approve provider access or run the prepared command where requested.
- Explicitly approve local log access when using an installed agent.
- Wait for a new message to be received and become searchable.
Creating a source alone does not mean every log is being collected. The connection flow prepares the selected source, activation and its credentials; collection follows your explicit choices and any required approval. Inspect the result rather than assuming that a saved name proves receipt.
MetriBeacon supports its agent, HTTPS JSON or NDJSON, OTLP/HTTP logs, TLS syslog and documented provider integrations. Choose the guide for the sender you actually use. An OpenTelemetry log integration does not imply support for every other telemetry signal. Provider permissions, plan requirements and possible charges still apply to external services.
For an existing agent, choose only the discovered logs you need and approve that selection locally. Other files require explicit local access. Use the latest released agent as the guide requires; connecting a source does not grant arbitrary file-reading permissions.
Review masking and retention before expanding collection
MetriBeacon masks known password, token, cookie, authorization and private-key fields before storage. You can add field or RE2 masking rules for application-specific secrets. Review your own data: an unusual field name or sensitive text may need an explicit rule.
Start with controlled, non-sensitive messages and inspect what becomes searchable before broadening collection. Avoid sending credentials or personal content simply because automatic masking exists. The agent also masks before its encrypted local buffer.
Sources retain logs for seven days by default. You can choose one to 30 days. Shortening retention requires confirmation; extending it later cannot restore deleted entries. Workspace access controls search, live viewing and downloads.
The log monitoring overview describes these boundaries and the first-source setup. Keep collection scope, retention and the reason for storing each source understandable to the people who use it.
Build a search around one investigation question
The explorer starts with the last 15 minutes. First choose the right workspace, source and time range. Then use severity, service, host or text to narrow the result.
The following examples use an illustrative service named api. Replace it with a value actually present in your log metadata. If a source does not supply that service field, adding the filter will not create it.
Find messages classified as error or a higher severity:
service:api AND level:>=error
Find messages mentioning either of two connection problems:
service:api AND message:~"timeout|connection refused"
Exclude hosts whose names start with staging from the error search:
service:api AND level:>=error AND NOT host:staging*
These are search examples, not reports of a real outage. RE2 matching applies to the selected text field; make the expression as specific as the question requires. Boolean operators let you combine conditions without turning every loosely related word into a match.
Use the record's normalized severity together with its message and attributes. The presence of the word “error” inside a message is not the same as an entry classified at error severity.
Read details, counts and live entries in context
Open a result to inspect its message, body, attributes, resource information and metadata. Compare timestamps with the incident history and a relevant deployment or application change.
The result table uses pages of 50 rows. Counts and histograms cover the complete filtered result for the selected snapshot, rather than only those visible rows. Wait for the statistics to complete before interpreting a count.
Live entries wait for your explicit action to show them, so incoming messages do not move the row you are reading. A paused or background view does not prove that a source stopped producing messages. Inspect the source's collection and indexing state separately.
Save a useful filter combination as a personal or shared view when you need it again. CSV and NDJSON exports use an authorized fixed snapshot and expire after at most 15 minutes. Download an export while it remains available and handle the resulting file according to its contents.
Turn a useful search into a log alert
Choose a condition that starts a concrete response. For example, a hypothetical rule might trigger on at least five matching API errors within five minutes. Review the rule preview, choose notification destinations and decide whether grouping by service or host helps the investigation.
MetriBeacon supports hit-count and silence rules with windows from one minute to six hours. A silence rule makes sense when you genuinely expect a message during that period; occasional application errors are not a regular heartbeat.
Alert rules keep their own search filter. Changing a saved explorer view does not silently change the rule. Review and update the alert itself when its intended condition changes.
Connect and test confirmed destinations using the alarm setup guide and the email and Telegram article. Decide what the recipient should inspect first: the matching entries, their source, the affected operation and its recent changes.
Treat missing logs as missing evidence
An empty search can have several explanations: no matching event occurred, the time range is wrong, a filter excludes the source, collection is disabled or accepted data is still waiting to be indexed.
Check those possibilities before declaring recovery. Quota rejection, agent buffer problems and indexing delays are incomplete observation. They do not confirm that a silence condition succeeded or that an earlier problem cleared.
Logs have their own daily allowance. Normal accounts start with one GiB of normalized, uncompressed accepted log volume per UTC day, shared across their workspaces. Unverified machine accounts start with 100 MiB. Consult the Logs usage section for your effective limits. Filtering can reduce accepted volume; masking does not reduce the bytes counted for that quota.
The heartbeat monitoring guide explains the broader distinction between a fresh successful observation and an old result followed by a gap. Apply the same care when reading log evidence.
Frequently asked questions about log monitoring
Do log sources need a separate monitor?
No. Log sources and their log alerts belong directly to a workspace. You can investigate them alongside existing monitors without creating a measurement series for every message.
Does an empty search mean the application is healthy?
No. Check filters, time range, collection, quotas and indexing before interpreting an empty result as absence of a problem.
Are all secrets removed automatically?
No. Known fields are masked, and custom rules are available. Review application-specific fields and messages before expanding collection.
Is log monitoring free with MetriBeacon?
MetriBeacon is free within its documented technical quotas. Logs use a separate daily budget. External providers may charge for forwarding or related infrastructure.
Start with one source and one useful question
Create a free MetriBeacon account, connect one selected log source and verify a new searchable message. Build a focused query, save the view and test one useful alert. The Website/API template below creates a complementary HTTP monitor; connect your logs separately through Logs → Sources.
