Logs

Preview · this stream is evolving

Three correlated log streams in one place — infrastructure, application, and audit — with retention, immutability, and export paths sized for SOC 2 and HIPAA. Where Tracking follows a single message and Monitoring shows current state, Logs is the evidence-grade historical record of everything else that happened.

Every customer eventually has to answer two questions that Tracking and Monitoring cannot: "who changed this, and when?" and "prove it for the auditor." Logs is the answer to both. It records the events the platform and its operators generate, keeps them long enough to satisfy compliance regimes the customer is most likely to be assessed against, and exposes them in shapes that a SIEM, an auditor, or a legal hold can consume.

Three streams live side by side on the Logs screen. Infrastructure logs capture what Azure itself emits about the resources Art2link runs on. Application logs capture what Art2link emits about its own runtime. Audit logs capture every operator action against the platform. They share one filter bar, one time picker, one export workflow — but each is stored, retained, and protected to a different standard, because each answers a different kind of question.

Overview

Three streams, one screen

Each stream has its own source, its own retention default, and its own immutability guarantee. The Logs screen presents them on one canvas so a single time range and a single filter expression can be applied across all three at once — useful when a single incident touches an Azure resource, an application path, and an operator action in the same minute.

The three streams differ on every dimension that matters to an auditor.

Stream	What it records	Default retention	Compliance lift
Infrastructure	Azure resource diagnostic and activity events — SQL audit, Key Vault access, Storage diagnostics, App Service stdout/stderr, Service Bus operations, NSG events, Azure RBAC role assignments.	90 days hot, 1 year archive	SOC 2 logical-access & change-management evidence at the platform layer.
Application	Art2link’s own structured emissions — port lifecycle, pipeline traces, adapter connects, map evaluations, runtime errors, deployment events. Correlated to Tracking IDs.	90 days hot, 1 year archive	SOC 2 system-operations evidence; supports HIPAA §164.312(b) audit-controls implementation.
Audit	Every operator action — sign-in, port create / change / delete, credential rotation, snapshot restore, retention-policy change, role assignment, log export.	1 year hot, 6 years archive	SOC 2 change-management & CC6/CC7 series; HIPAA §164.308(a)(1)(ii)(D) & §164.312(b) audit controls.

Stream

Infrastructure logs

Everything Azure itself records about the resources Art2link runs on. The platform turns on the diagnostic-setting and audit feeds that compliance frameworks expect and routes them all into one queryable workspace so an investigator does not have to walk the Azure portal resource by resource.

Source	What it captures	Why it matters
Azure SQL audit (Art2linkDB, TrackingDB)	Every login, every schema change, every query execution that touches an audited table.	SOC 2 logical access at the database layer; HIPAA evidence that PHI-bearing tables are not read off-policy.
Key Vault diagnostics	Secret get / set / delete, key wrap / unwrap, certificate operations — with caller identity.	Proves credential rotations actually happened, and that nothing outside the platform pulled a secret.
Storage account diagnostics	Blob and file read / write / delete operations with caller identity and source IP.	Required when message payloads or audit exports are persisted to blob.
App Service logs	Process stdout / stderr, deployment events, container restarts, autoscale actions.	The first place to look when a runtime error is shaped like a platform issue, not an integration issue.
Service Bus operational logs	Namespace operations, throttling events, dead-letter actions.	Correlates throttling visible in Monitoring back to the responsible client or namespace operation.
Azure Activity log	Subscription-level changes — resource creates / deletes, role assignments, policy edits.	The change-management spine. Any “who scaled this tier?” question lands here.
Sign-in & Entra ID logs (where applicable)	Tenant sign-ins, conditional-access decisions, MFA challenges.	Authentication evidence below the Art2link layer.

Infrastructure logs are sourced, not generated. The platform consumes what Azure already emits — it does not invent a parallel record. That keeps the stream defensible: an auditor can reconcile what Logs shows against the same events in the Azure portal and they will match.

Stream

Application logs

What Art2link’s own software writes as it runs. These are structured JSON events with a fixed envelope so a single KQL query can filter across the whole platform without parsing free-form strings. Where Tracking answers what happened to this message, application logs answer what was the runtime doing at the time.

Event class	Examples
Port lifecycle	Port started, stopped, paused, restarted; adapter connection opened, closed, failed; listener bound to endpoint.
Pipeline trace	Each pipeline component’s entry, exit, and outcome — without payload, distinct from the body-bearing Tracking record.
Map evaluation	Map invoked, custom function called, validation failure, transformation error.
Runtime error	Unhandled exceptions with stack, correlation ID, originating port, and the Tracking step ID they belong to.
Deployment event	NuGet package published, snapshot generated, snapshot restored, configuration applied.
Background job	trackingdb-prune, index-maintenance, snapshot-generate, secret-expiry-scan, backup-verify — entry, exit, duration, outcome.

Every record carries the same envelope:

Field	Purpose
`timestamp`	UTC, sourced from the host’s NTP-synced clock.
`tenant`	Always present, even on single-tenant deployments — keeps the schema portable.
`application` / `port`	The configured objects the event came from, where applicable.
`tracking_id`	Correlates the line into a Tracking run when one exists.
`level`	`debug` / `info` / `warn` / `error` / `fatal`.
`event`	A stable, machine-readable event name (e.g. `port.lifecycle.started`).
`actor`	Always `system` for application logs — operator-attributed events live in the audit stream.

Stream

Audit logs

The compliance-grade record of every operator action against the platform. Lightweight by design — no payloads, no message bodies — but exhaustive in coverage: if a human or a service principal changed something, it shows up here.

Category	Tracked actions
Identity	Sign-in, sign-out, failed sign-in, MFA challenge result, session expiry, impersonation start / end.
Configuration	Application, port, pipeline, map, schema, variable, constant, custom function, pipeline component — create, update, delete; before / after diff on update.
Credentials	Adapter credential rotated, Key Vault secret reference changed, API key issued / revoked, certificate uploaded.
Runtime control	Port started / stopped, suspended run resumed / terminated, deployment promoted between environments.
Administration	User added / removed, role granted / revoked, RBAC policy edited, tenant setting changed.
Snapshots & retention	Snapshot generated, snapshot restored, retention window changed, log export downloaded.
Self-audit	Audit-log read, audit-log export, retention-policy change on the audit stream itself — the audit stream watches itself.

Every record carries the actor envelope:

Field	Purpose
`timestamp`	UTC, NTP-synced; the audit stream additionally records source-clock skew when it exceeds 250 ms.
`actor.type`	`user`, `service_principal`, or `system`.
`actor.id` / `actor.email`	The identity that performed the action.
`source_ip` / `user_agent`	Where the action originated.
`action`	Stable verb (e.g. `port.update`, `credential.rotate`).
`target`	The object the action ran against, fully qualified.
`before` / `after`	JSON diff for configuration changes; `null` for actions without a stateful before/after.
`hash_prev` / `hash_self`	Hash-chain links that make the stream tamper-evident — see Retention & immutability.
`outcome`	`success` / `denied` / `error`; denied actions are recorded with the same weight as successful ones.

Denied actions are first-class records. An attacker probing a port they cannot edit looks identical to a benign mis-click until you read the audit log. Both attempts are written; the operator role only sees the ones attributable to them, the auditor role sees everything.

Posture

SOC 2 and HIPAA

The three streams together are the platform’s answer to the two compliance regimes the customers are most often assessed against. The point is not that Art2link makes a customer SOC 2 or HIPAA compliant by itself — that remains a programme-level conclusion — but that the platform never becomes the reason the assessment stalls.

Requirement	How Logs satisfies it
SOC 2 CC6 — Logical & physical access	Sign-ins, role grants, denied access attempts all land in the audit stream. Infrastructure sign-in logs corroborate from the Azure layer.
SOC 2 CC7 — System operations	Deployment events, maintenance-job outcomes, and runtime errors are persisted in application logs; corresponding Azure resource events in infrastructure logs.
SOC 2 CC8 — Change management	Every configuration change — port, map, schema, pipeline — carries a before / after diff, an actor identity, and a timestamp in the audit stream.
HIPAA §164.308(a)(1)(ii)(D) — Information system activity review	Audit-log retention defaults to 6 years, the HIPAA documentation retention period. Application logs cover the activity-review surface.
HIPAA §164.312(b) — Audit controls	Hash-chained, append-only audit stream with RBAC-scoped reads and immutable archive storage satisfies the “hardware, software, and procedural mechanisms” clause.
HIPAA §164.312(c)(1) — Integrity	The hash chain detects retroactive modification; the immutable archive prevents it.
HIPAA §164.312(d) — Person or entity authentication	Every audit record carries an actor identity. Anonymous writes are not possible.
BAA — Business Associate Agreement	Logs are stored within the customer’s Azure tenant on Azure services covered by Microsoft’s BAA; no third-party log SaaS is in the path by default.

The compliance posture is the defaults, not the ceiling. Retention windows, immutability windows, and the set of routed event sources can all be tightened above the defaults for customers in stricter regulatory regimes (PCI‑DSS, HITRUST, FedRAMP-aligned). Loosening below the defaults requires an explicit configuration change that is itself audited.

Storage

Retention & immutability

Each stream moves through three storage tiers as it ages. Hot tier is queryable from the Logs screen with sub-second latency. Warm archive keeps the same query interface but at a higher latency and a lower per-GB cost. Cold archive is offline blob storage with an immutability policy — bring-back-on-demand for an auditor or a legal hold.

Stream	Hot	Warm archive	Cold / legal hold
Infrastructure	90 days	1 year	configurable
Application	90 days	1 year	configurable
Audit	1 year	6 years	immutable, configurable beyond 6y

Immutability is enforced at the storage layer, not the application layer. The platform writes; nothing in the platform can rewrite or delete an archived record before its retention expires — not an operator, not a tenant admin, not the platform itself. Three mechanisms make that guarantee load-bearing:

Mechanism	What it does
Append-only writes	The platform has no update / delete path on a log record. The schema does not even model one.
Hash-chained audit stream	Each audit record references the hash of the previous record. Any retroactive edit breaks every subsequent link — detectable by recomputing the chain.
Immutable archive policy	The cold-tier blob containers carry a time-based immutability policy. Records cannot be deleted until the policy clock expires, regardless of credentials.
Authoritative time	All three streams use the host’s NTP-synced clock. Skew > 250 ms is itself an audit event — the timeline cannot be quietly bent.

Access

Reads, RBAC, and export

Reading and exporting logs is itself audited. Every export records what was extracted, by whom, for what time range, and to which destination — an export of the audit stream produces an audit record about the export.

Role	Default access
Operator	Read infrastructure and application logs. Read own audit actions. No export.
Tenant admin	Read all three streams. Export with throttled volume. Cannot change retention or immutability windows.
Auditor	Read-only across all three streams including the warm archive. Full export.
Compliance admin	All of the above, plus the ability to change retention and immutability windows. Every such change is an audit event.

Three export shapes ship by default. A fourth, custom-formatted export for a specific SIEM is a configuration, not a code change.

Format	Use
CSV	Spreadsheet-shaped, suitable for ad-hoc auditor review.
JSONL	One JSON record per line. The native shape; round-trips into any SIEM that accepts JSON.
Syslog (RFC 5424)	Streamed forwarder for SIEMs that prefer a tail rather than a batch.
Legal-hold bundle	A signed, hash-manifested archive of a specified time range across all three streams — the shape an outside counsel or regulator typically asks for.

Status

Logs is in active development. The framing on this page is the target shape of the screen and the storage model it ships against in the first complete release. Infrastructure and application streams are available in both Starter and Enterprise; the audit stream, hash-chained storage, immutable archive, and legal-hold bundle export are Enterprise.

That’s Logs

Three correlated streams — infrastructure, application, audit — with retention, immutability, and export sized for SOC 2 and HIPAA. Tracking shows what happened to a message; Monitoring shows whether the plant is healthy; Logs is the evidence record everything else stands on.