> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/operations/which-log-to-read.md). # Which log answers which question A routing page for an administrator holding a symptom — what the audit log answers, what each service log is responsible for, which one to open for a given failure, and what no log records at all. ## What this is, and when you need it You have a symptom and you need one place to look. This page is the map: the audit log answers *who changed what*, each service log answers *what happened inside one component*, and the two answer different questions badly if you swap them. Everything here is read-only. You do not need shell access to use this page. Retrieving a service log is deployment-level work and the procedure lives in the [Installation Guide](/installation/installation.md) — what you need from here is the *name* of the log to ask for, the minute to ask about, and the line to ask them to search for. Handing over "something is broken with provisioning" produces a day of nothing; handing over "the `idm` service log, 14:32 to 14:36, search for `Business Rule Service is not run`" produces an answer. ## The audit log answers "who and what", not "did it work" The audit log is the record of intent and authorship. It is an OpenSearch index rather than a database table, it is kept indefinitely on a shipped installation, and one operation is a *tree* of events linked by a parent id. Read it at `/webconsole/viewAuditLog`; open a single event at `/webconsole/auditLog?id=`. The model, the search parameters and the export mechanism are in [Find audit evidence](/administration-guide/operations/find-audit-evidence.md) — this section is only the boundary of what it can tell you. | The audit log records | The audit log never records | | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Who requested a change, when, from which address, session and node | What the managed system actually did — the target's own protocol error reaches no OpenIAM record | | `SUCCESS` or `FAILURE` per event, in a parent/child tree | Anything a service caught and swallowed: a Groovy script that failed to instantiate, business rules skipped for a missing consumer, a notification abandoned for a missing address | | Before and after values, for the eleven user-changing actions that render them | Its own failures — a failed audit write and a failed export dispatch are logged, not audited | | The provisioning stream: the ordered resources an operation *intended* to touch | Anything below the OpenIAM services — the gateway, the front-end web server, the broker | | The connector's reply, as a child event correlated by the parent audit log id | Whether a value it stored was truncated, or whether the event you are missing was ever attempted | {% hint style="warning" %} **A successful save is not evidence of an outcome, and neither is a successful parent event.** A parent that reports `SUCCESS` completed *its own* work; the asynchronous child that touched the managed system can have failed underneath it. Always take the parent audit log id and look for its children before you conclude an operation worked — see [Find the evidence for one change](/administration-guide/operations/find-audit-evidence.md#find-the-evidence-for-one-change). {% endhint %} ## The service logs, and what each one is responsible for Each OpenIAM service keeps its own log, and what a log can explain follows exactly from what its service is responsible for. The last column is what to ask for by name when someone else fetches it. | Log | The service is responsible for | So its log explains | Ask for it as | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | **ESB** | The front door for the UI services and the gateway: authentication rule evaluation, adaptive risk, content-provider and URI-pattern resolution, password-policy resolution, mailbox rotation, OTP generation, certificate and CRL handling, geolocation | Sign-in refusals with no user-visible reason, a risk step that failed open instead of evaluating, a content provider that never matched, a custom resolver or risk script that fell back silently | `esb` | | **UI services** | Rendering the screens, holding the browser session, and writing the audit event the screen caused — Webconsole, SelfService, the IdP, and the report viewer, each on its own path | A screen that will not load or renders empty, a session or cookie question, and whether a request arrived through the gateway at all | `webconsole`, `selfservice`, `idp`, `reportviewer` — name the one that served the URL | | **IDM** | Building and dispatching every provisioning operation, running business rules, pre- and post-processors, and the data-validation script | A provisioning operation that reported success and changed nothing, entitlements missing across many users at once, a processor that was never loaded | `idm` | | **Synchronization** | Reading source records, matching them to identities, running transformation scripts | Records skipped or unmatched, a source query the connector could not answer, a binding that never reached a transformation script | `synchronization` | | **Reconciliation** | Comparing OpenIAM against a managed system and applying the situation responses | A run that processed zero records with no errors, a situation script that failed to compile, a pre- or post-processor whose failure left nothing on the audit entry | `reconciliation` | | **Workflow** | Activiti: approval processes, candidate resolution and task assignment, escalation, the membership grant that follows an approval, and certification reviewer tasks | A request that reads Approved while the membership is absent, an approver level that silently went missing, reviewers who have no task although review items exist | `workflow` | | **Certification** | Campaign previews, launch, review items, and report chunking and assembly — the whole subsystem except the reviewer workflow, which is Activiti | A campaign that generated nothing, a preview that never started, a custom helper script that silently did not load, a report that never assembled | `certification-manager` | | **Risk** | Identity and entitlement risk scores, the nightly convergence sweep, and publishing score changes | Scores that never refresh, a sweep that never completes, a risk-filtered campaign whose scope came back empty | `risk-manager` | | **Mail** | Resolving the recipient address, fetching and rendering the template, handing the message to SMTP, and sweeping the reply inbox | A notification nobody received, a disabled or renamed template, a recipient with no active address — none of which fails an audit event | `email-manager` | | **Audit** | Stamping, writing and exporting audit documents | Audit events missing for operations you know happened, and a SIEM feed that stopped without any screen saying so | `audit-log-manager` | | **Batch tasks** | The scheduling cycle and every batch task run | Tasks that stopped running with no failure recorded anywhere, and a cron that fired in an unexpected hour | `batch-task-manager` | | **Groovy** | Caching and serving script bodies to every service that runs one | A script edit that appears not to have taken effect — `Failed to put groovy script in cache.` is written here and reaches no screen | `groovy-manager` | | **Authorization graph** | Building and holding the graph that effective access is computed from | Whether a requested rebuild finished, and how long it took. The rebuild request's own response only confirms it was accepted | `auth-manager` | | **Connector runtime** | Talking to the target. It runs outside OpenIAM, in its own container or as a Windows service | Every target protocol error — bind failures, schema violations, LDAP referrals, attributes the target rejected — and a connector that consumes a request and never answers it | The connector's own log on its host. Give the managed system name and the minute | | **Access Gateway** | Matching the request to a content provider and URI pattern, enforcing the decision, and proxying to the right upstream | Requests that never reached OpenIAM at all, upstream and proxy failures, and the module's own matching decision | The gateway's error log and its access log, which are separate from every OpenIAM service log | One thing about that last row will mislead you if you meet it cold: in a container deployment an **empty gateway log is a configuration state, not evidence that no request arrived**, and the shipped starter configuration puts passwords and session tokens into whatever collects your logs. Both are explained in [Diagnose a failed operation](/administration-guide/operations/diagnose-a-failed-operation.md#the-access-gateway). {% hint style="info" %} **"The provisioning service log" and "the IDM log" are the same file.** Provisioning runs inside the `idm` service; both names appear in this guide and in support tickets. Synchronization and reconciliation, by contrast, really are separate services with separate logs. {% endhint %} ## Which log to read for a given symptom Start at the left. The middle columns are ordered — open the first, and only go to the second if the first is silent. | Symptom | Read this first | Then | What you are looking for | | ------------------------------------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A provisioning operation reported success and the managed system never changed | The audit tree — parent, then children | `idm`, then the connector's own log | A `CONNECTOR_RESPONSE` child at all. No child means OpenIAM never asked; a failed child means the target answered and the reason is in the connector's log | | Provisioning succeeded, the account exists, and it carries no entitlements | `idm` | The audit event's `BUSINESS_RULE_EXPLANATION` attribute | `Business Rule Service is not run. Skip Business Rule processing`. Rules were skipped and nothing failed. The attribute's absence on a successful operation is the same finding | | A pre- or post-processor appears to do nothing | `idm`, at debug | — | `.add was called, which is a NO-OP`. That line means the default processor ran and yours was never loaded | | A synchronization skipped records, and source and OpenIAM counts do not reconcile | `synchronization` | The run's audit children | `Line object doesn't contain the match field. Object from source:`. A record whose match column is **blank** logs nothing at all — count those in the source yourself | | A synchronization returned nothing from the source | `synchronization` | The managed system's `connectorreply` documents | The `QUERY was:` line beside the failure — it prints the query actually sent | | A field in a synchronization or reconciliation script is unexpectedly null | The log of whichever service ran it, at debug | — | `Ignoring field in script