Monitor IFS integrations with Azure Monitor

Explore this learning path

Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.

Collect a controlled integration-worker log with Azure Monitor Agent (AMA), query a correlation ID, and create an alert for failed operations. This procedure monitors infrastructure you administer; it does not install an agent into an IFS-managed Cloud service.

Before you start

You need an Azure subscription, a Log Analytics workspace, a supported Azure VM or Azure Arc-enabled server, and permission to configure AMA and Data Collection Rules (DCRs). Choose an integration worker/Print Agent host whose logs you are authorized to collect.

Start with a dedicated lab file containing no credentials or business payloads. Agree retention and access to the workspace before collecting real logs.

1. Write a structured test log

On the Windows worker host, create a folder such as C:\IntegrationLab\Logs. Append this single-line JSON record to lab.log in UTF-8:

{"time":"2026-09-27T10:00:00Z","correlationId":"LAB-MON-031","operation":"read-status","outcome":"failed","status":503,"durationMs":1250}

Use the current UTC time when running the test. Append new lines rather than overwriting the file. Do not rotate a file into another name matching the collection pattern, which can ingest the same content twice.

2. Prepare the workspace table

In the Log Analytics workspace, create a custom table named IntegrationLab_CL. Its schema must include TimeGenerated as datetime and RawData as string. Optionally include Computer and FilePath as strings for source identification.

Use the custom-table creation workflow described in custom text-log collection. This tutorial keeps the full sanitized line in RawData and parses it at query time, so there is no custom ingestion parser to debug initially.

3. Configure the Data Collection Rule

1. Open Azure Monitor → Data Collection Rules and create a rule in the appropriate region.
2. Select the supported resource/host and add a data source of type Custom Text Logs.
3. Set its file pattern to C:\IntegrationLab\Logs\*.log.
4. Select the compatible record timestamp/delimiter option. For this one-line JSON fixture, ensure each line becomes one record rather than a multiline group.
5. Select the Log Analytics workspace and IntegrationLab_CL as the destination table.
6. Use a pass-through transformation, source, for the RawData-based schema.
7. Associate the rule with the host and confirm AMA is installed and healthy.

Allow ingestion time, then append a second record with a fresh timestamp/reference. Do not conclude the rule is broken solely because a line written before configuration has not appeared.

4. Find the operation by correlation ID

Run this in the workspace’s Logs editor:

IntegrationLab_CL
| where TimeGenerated > ago(2h)
| extend event = parse_json(RawData)
| where tostring(event.correlationId) == "LAB-MON-031"
| project TimeGenerated,
          correlationId=tostring(event.correlationId),
          operation=tostring(event.operation),
          outcome=tostring(event.outcome),
          status=toint(event.status),
          durationMs=tolong(event.durationMs)

The expected row has operation read-status, failed outcome, and status 503. If RawData exists but parsed fields are empty, inspect the stored line for a prefix or malformed JSON and adjust the parser to the actual log format.

5. Create and test an alert

Change the query to filter tostring(event.outcome) == "failed" over an agreed recent time window. From the query results, create an alert rule with a row-count threshold greater than zero and an action group owned by the integration support team.

Inject one new lab failure and verify that the alert fires with the expected scope. Then send only successful records and confirm it resolves according to the chosen evaluation settings. Document the evaluation interval, window, and severity; otherwise a useful query can become a noisy alert.

6. Diagnose missing evidence and clean up

Check in order: file path/encoding, newly appended line, AMA health, DCR association, destination table, workspace permissions, and query time range. UTF-16 files and unsupported path patterns are common ingestion mistakes.

For real integrations, propagate the same correlation ID through the worker, gateway, and IFS message/reference records. Log timings and outcomes, not bearer tokens or entire documents. Remove the lab alert/DCR association and test file when finished, leaving any shared monitoring configuration intact.

Sources and scope

• Azure Monitor Agent overview
• IFS Connect architecture

Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.