> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neuro-tech.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Observe a Neuron

> Use event logs, exception logs, sniffers, notifications, and queues

Start every investigation with the structured event log. Add protocol sniffers only when the event data is insufficient.

## Event levels

| Level         | Use                                             |
| ------------- | ----------------------------------------------- |
| Debug         | Developer diagnostics; normally high volume     |
| Informational | Normal operational activity                     |
| Notice        | A significant condition or configuration change |
| Warning       | A condition that can become an error            |
| Error         | An expected operation failed                    |
| Critical      | An unexpected failure that can escalate         |
| Alert         | Immediate operator action is required           |
| Emergency     | The system is or is becoming unusable           |

Use stable event IDs for machine processing. Add actor, object, facility, module, and structured tags rather than embedding all context in the message.

## Exception logs

Exception logs preserve stack traces and nested exceptions that may be abbreviated in the event view. Correlate them with the event timestamp, actor, resource, and request ID. Remove secrets and unnecessary personal data before sharing a trace.

## Protocol sniffers

Sniffers can capture HTTP, XMPP client-to-server, XMPP server-to-server, SMTP, ledger, and other protocol traffic provided by installed modules.

<Warning>
  A sniffer can capture credentials, tokens, message bodies, identity data, and contract content. Limit its duration and audience, and delete captures according to your incident-data policy.
</Warning>

## Operator notifications

Notification settings determine which events are only logged and which are pushed to operators. Configure high-signal events such as account or API-key creation, recovery requests, legal-identity review, automatic approval/rejection, and contract proposals. Avoid routing high-volume informational events as immediate alerts.

## Queue event sink

An `EventQueue` sink can persist events in an encrypted FIFO queue so producers do not block on downstream processing. Configure a queue name, retention period, and sink ID in `Gateway.config` or the gateway configuration source. Consumers can dequeue locally or use the Queue API.

Queue design rules:

* make consumers idempotent;
* persist the last processed business identifier, not only an in-memory offset;
* choose retention longer than the maximum expected outage;
* monitor queue depth and oldest-item age;
* send poison events to an explicit dead-letter workflow.

## Investigation order

1. Confirm service state and current build.
2. Search events around the first failure.
3. Open the linked exception, if any.
4. Check package/module load events after the last restart.
5. Inspect listener and connection state.
6. Enable the narrowest relevant sniffer for a short reproduction.
7. Disable the sniffer and preserve only the evidence required.