Unit 7.2: Observability and Operations

Introduction

Observability on IONOS is not one product. It is four separate planes, each with a fixed scope, its own ingestion path, and its own retention model. The architectural work is not "turn on monitoring"; it is deciding which signal lands in which plane, where the seams between planes are, and how you stitch a single operational picture across them and across contracts.

FinCorp, our German financial-services firm under GDPR and BSI obligations, needs an audit-grade operational view spanning a regulated workload core, a Managed Kubernetes platform, and a dedicated VMware estate, which exposes every seam in the platform's telemetry model. This unit walks the four planes, names the gaps honestly, builds a metrics pipeline with an alert and a flow log in the Data Center Designer, and closes on the fan-in pattern that gives FinCorp one place to correlate.

1. The Four Telemetry Planes and Their Fixed Scopes

The platform splits operational signal across four products. None of them is a superset of the others, and the boundaries are hard, not conventions.

Metrics (Monitoring Service). A per-contract, per-region service that ingests Prometheus-format metrics (Counter, Gauge, Histogram, Summary), with a JSON alternative that must be compressed using Snappy. Metrics are pushed by an agent: Prometheus, Grafana Agent, OpenTelemetry, or Fluent Bit, at a default push interval of 1 minute that is configurable. Behind the endpoint the data lands in Grafana Mimir and is visualised in a managed Grafana instance scoped per contract and per region. You can run up to 10 pipelines per contract.

Logs (Logging Service). A per-contract, per-region service that ingests log streams from a fixed set of sources: Kubernetes, Docker, Linux Systemd, HTTP (a JSON REST API), and Generic. Transport is TLS over either TCP (Fluent Bit forward, port 9000) or HTTPS (port 443). Each pipeline carries up to 5 log streams, you can run up to 10 pipelines per contract, and per-stream retention is 7, 14, 30 days, or unlimited (default 30). Logs surface in the same managed Grafana, but the Grafana query window is 30 days; anything kept under unlimited retention is read back by raising a support request, not in the dashboard.

Audit (Activity Logs). The control-plane audit trail: who did what to which resource. It records user logins, resource provisioning, configuration changes, data access, and resource retrievals, modifications, and deletions. It is read-only by design, every call is a GET against https://api.ionos.com/activitylog/v1, and retention is 35 days. This is a governance plane, covered in depth in Unit 2.3; here it matters because its short window forces an export discipline that the metrics and logs planes do not.

Network flow (Flow Logs). Per-flow connection records (5-tuple plus packet and byte counts, plus an action field of ACCEPT or REJECT showing the firewall verdict) emitted to a customer-owned Object Storage bucket as gzip-compressed text, rotated every 10 minutes. Flow Logs attach to a VM NIC, a Managed Network Load Balancer, a Managed Application Load Balancer, or a Managed NAT Gateway, and capture IPv4 and IPv6. This plane is built in Unit 3.2 as the firewall verification tool; it reappears here as the network-layer leg of the operational picture.

The unifying surface is Grafana: metrics and logs are both queryable through one managed Grafana instance per contract per region. The deliberate design point is that audit and network-flow data live entirely outside that pane, in the Activity Log API and in Object Storage respectively. A complete operational view is something you assemble, not something the console hands you.

2. The Gaps to Design Around

Three boundaries are the ones that bite in production. Each is a design input, not a defect, and each has a native composition around it.

Kubernetes control-plane events do not flow through the Logging Service. The Logging Service lists Kubernetes as a supported source, but that means workload and node logs you ship from inside the cluster, not the managed control plane. The IONOS Managed Kubernetes SLA covers only the Kubernetes API of the control plane, and control-plane events are not emitted into your Logging Service pipeline. The cluster does offer a separate "Logging to S3" toggle that writes cluster log data to an Object Storage bucket; treat that as a distinct, separately enabled path, not as control-plane visibility in your Grafana. For workload observability you deploy an in-cluster agent (Fluent Bit for logs, a Prometheus-compatible exporter for metrics) that pushes to your Logging and Monitoring pipelines. The seam is the line between the managed control plane and your workloads: you instrument the latter, IONOS operates the former.

There is no cross-contract aggregation. Monitoring and Logging pipelines are per-contract and per-region, and the Activity Log is per-contract with no push and no aggregation endpoint. If FinCorp splits production, non-production, and a compliance-isolated workload across separate contracts (the boundary discipline from Unit 2.1), there is no native pane that unions their telemetry. Aggregation is something you build, by fanning every contract's signal into one external collector (Section 5).

The Activity Log retention window is 35 days. That is the hard deletion horizon for the audit trail. For a regulated firm whose retention obligations run to years, the 35-day window is an export deadline, not a retention policy. The documented long-term pattern is to download Activity Log data on a schedule and store it on different storage, with IONOS Cloud Object Storage as the explicitly recommended target, ideally under object lock for a tamper-evident archive (Unit 2.3, Unit 5.2). Miss the window and the record is gone.

3. Central Logging and Hybrid vCenter Observability

3.1 Central Logging for product-initiated forwarding

By default you ship logs yourself, by pointing an agent at a pipeline endpoint. Central Logging is the contract-level, per-region switch that lets integrated IONOS Cloud products forward their own logs to the Logging Service on your behalf, surfaced in the same managed Grafana, without each product running a separate ingestion stack. A Managed Network Load Balancer, for example, sends its access logs to your Logging Service once Central Logging is enabled. The same model extends to Central Monitoring for the Monitoring Service.

Central Logging must be activated before any product can ingest on your behalf, because it affects both your operational view and your billing. Activation is per region, and only contract administrators, owners, and users with the "Access and manage Logging Service" privilege can toggle it. It can be enabled from the DCD (a per-region STATE toggle in the Logging Service Central Logging view), from the Logging API, or by an integrated product on your behalf. Which products integrate is confirmed through your account manager or IONOS Cloud Support rather than published as a static list, so treat the supported set as something to verify per engagement.

3.2 vCenter observability for the dedicated-VMware estate

FinCorp's regulated core runs on IONOS Private Cloud, the dedicated managed VMware SDDC (Unit 4.4). Its telemetry does not flow into the four platform planes. Instead, observability for that estate is the native VMware tooling that ships with the dedicated stack: vCenter Server 8.0 for host, cluster, and VM performance charts, events, and alarms, and vSAN health and capacity monitoring exposed in the Cloud Panel for the storage layer. The vSphere REST API (rate-limited to 100 requests per second) is the programmatic seam if you want to pull that data outward.

State only what the matrix supports here: the dedicated-VMware observability surface is vCenter and vSAN. Do not assume a managed cross-plane bridge that ingests vCenter alarms into the Logging Service; none is documented. For a hybrid estate the honest model is two observability domains running side by side, the four platform planes for cloud-native resources and vCenter/vSAN for the dedicated VMware core, reconciled only where you deliberately forward both into a common external collector.

4. DCD Implementation Walkthrough

You will stand up the metrics leg of FinCorp's operational view and the network-flow leg: a metrics pipeline with an alert, and a flow log on the edge load balancer. This realises two of the four planes from Section 1 and gives you concrete ingestion endpoints to point agents at. The third leg, logs, follows the identical pipeline pattern in the DCD.

Build goal: Create a metrics pipeline with an alert and enable flow logs.

Prerequisites. An existing Object Storage bucket in the target region that you own (the flow-log destination must be a user-owned bucket). The "Create Flow logs" privilege for the flow-log work, and the "Access and manage Monitoring" privilege for the metrics pipeline. Outbound HTTPS on port 443 from wherever your metric agents run.

Part A: the metrics pipeline (Monitoring Service). Note an important platform boundary: the Monitoring Service metric pipeline is created through the Monitoring Service API, not through a DCD create form. The pipeline lifecycle (create, retrieve, modify, delete) is API-only at this time; the DCD surface is for accessing the resulting Grafana, not for provisioning the pipeline. Treat the following as the API-level create path, then move into Grafana for alerting.

Pick the regional endpoint that matches your data placement, for example https://monitoring.de-txl.ionos.com/pipelines for Berlin. The region determines where metrics are processed and stored, so keep it consistent with the workload's residency decision.
Create the pipeline with a PUT (or POST) to that endpoint carrying a properties.name, authenticated with a Bearer token. The response includes a one-time key in its metadata and a grafanaEndpoint. Save the key on creation; for security it is not returned again, and you cannot push metrics without it.
Configure a metric agent (Prometheus, Grafana Agent, OpenTelemetry, or Fluent Bit) to push to the pipeline's HTTP endpoint with api/v1/push appended to the path, sending the saved key as a Bearer authorization header over port 443. Metrics arrive on the default 1-minute interval unless you change it.
Open the managed Grafana at the returned grafanaEndpoint and confirm the metrics are queryable, which verifies ingestion end to end.
Create the alert inside Grafana: define an alert rule on the metric you care about (for FinCorp's stateless app tier, a CPU-utilisation threshold that should precede an auto-scaling action), and attach a contact point so the rule notifies the on-call channel. Grafana alerting is the alerting surface; there is no separate IONOS alert object for the metrics plane.

A short illustrative create call (the architectural point is that this plane is provisioned through the API, not the console):

curl --location --request POST 'https://monitoring.de-txl.ionos.com/pipelines' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer $TOKEN' \
  --data '{ "properties": { "name": "fincorp-app-metrics" } }'

Part B: the flow log (DCD). This leg is a true DCD build, attached to a resource you already have from Module 3.

In the DCD, open the data center, select the edge resource whose traffic you want to record. For a server or Cube, open the Network tab and the properties of the Network Controller (NIC); for a Managed Network Load Balancer, Managed Application Load Balancer, or Managed NAT Gateway, open the Settings tab in the Inspector pane.
Open the Flow Log drop-down and create a rule. Set a Name (it also becomes the first part of the Object Storage object-name prefix), so name it for the resource and environment.
Set Direction to Ingress, Egress, or Bidirectional, and Action to Rejected, Accepted, or Any. For a security-investigation posture, Bidirectional plus Rejected surfaces what the firewall is blocking; for capacity and connection analysis, Accepted is the useful set.
Set the Target Object Storage bucket to your existing user-owned bucket in the region. Save. Records begin landing as .log.gz objects, rotated every 10 minutes.
Apply a lifecycle policy on that bucket to age the flow-log objects out, because Flow Logs have no built-in retention: retention is entirely customer-managed through an Object Storage Lifecycle Policy or manual deletion.

Common mistakes:

Expecting a DCD "create pipeline" button for metrics. The Monitoring Service pipeline is API-provisioned; only the Grafana access lands in the DCD experience. Plan the metrics build as an API step, not a console click.
Not saving the monitoring pipeline key at creation. The key is returned once and never again. Lose it and you re-create the pipeline. The same one-time-key rule applies to a Logging Service pipeline.
Treating "Kubernetes" in the Logging Service source list as control-plane visibility. It is your in-cluster workload logs only; control-plane events never arrive there. Deploy an in-cluster agent and do not wait for events that will not come.
Assuming flow-log retention is managed for you. Deleting the flow-log rule does not delete the objects already written, and there is no automatic expiry. Without a bucket lifecycle policy the archive grows and bills forever.
Pointing a flow log at a bucket you do not own or one in the wrong region. The destination must be a user-owned bucket; mis-targeting silently fails to deliver records.
Leaving an idle pipeline running. A Logging or Monitoring pipeline bills from creation to deletion regardless of whether any data flows; stopping the agent does not stop the charge. Delete pipelines you are not using.
Forgetting the Activity Log 35-day window. It is not retention, it is a deletion horizon. Schedule the export to Object Storage before day 35, or the audit record is unrecoverable.

5. Fan-In to an External SIEM

For an enterprise like FinCorp, the per-contract, per-region, four-plane model does not produce the single correlated view that a security operations team and an auditor both need. The enterprise pattern is fan-in: every plane from every contract flows into one external SIEM that becomes the system of record for correlation, long-term retention, and alerting across the estate. The platform gives you the seams to do this without a managed forwarder:

Logs and metrics: point your agents (or Central Logging's product-initiated forwarders) at the IONOS pipelines for in-platform Grafana, and in parallel forward the same streams from your agents to the SIEM collector. The Logging Service also exposes a read-only Telemetry API (/api/v1/query, /api/v1/query_range, /api/v1/series, authenticated with the same Cloud API token) that a SIEM can poll, though agent-side dual-shipping is the more direct route.
Network flow: Flow Logs already land in Object Storage as gzip text; the SIEM ingests them from the bucket, which doubles as the durable archive.
Audit: a scheduled job pulls the Activity Log via its GET-only API before the 35-day window closes and forwards records into the SIEM, simultaneously satisfying long-term retention and cross-contract correlation.
Hybrid VMware: the vSphere REST API and vCenter alarms are forwarded from the dedicated estate into the same SIEM, bringing the two observability domains together at the one point where unification is meaningful.

This is the same composition lesson the platform repeats elsewhere: there is no managed cross-contract aggregation product, so you compose one. Object Storage is the durable hub, the SIEM is the correlation brain, and the per-plane endpoints are the taps.

Summary

IONOS observability is four fixed-scope planes (metrics via the Monitoring Service, logs via the Logging Service, audit via Activity Logs, and network flow via Flow Logs) unified only partially, in Grafana, with audit and flow data living outside that pane by design. The load-bearing operational work is routing each signal deliberately, designing around the three gaps (no control-plane events in the logging plane, no cross-contract aggregation, a 35-day audit window), using Central Logging for product-initiated forwarding, treating the dedicated-VMware estate as a separate vCenter/vSAN observability domain, and fanning everything into an external SIEM where correlation and long-term retention actually happen.

Key Points:

Four planes, fixed scopes: Monitoring Service (Prometheus metrics, push-based, Grafana Mimir), Logging Service (five source types, 5 streams per pipeline, 7/14/30/unlimited retention), Activity Logs (read-only GET, 35-day window), Flow Logs (5-tuple records to a user-owned Object Storage bucket, customer-managed retention).
The Monitoring Service metric pipeline is API-provisioned, not a DCD create form; the one-time pipeline key must be saved at creation, and idle pipelines still bill.
Kubernetes control-plane events never reach the Logging Service; instrument workloads with an in-cluster agent and treat cluster "Logging to S3" as a separate path.
There is no cross-contract aggregation and the audit trail deletes at 35 days, so aggregation and long-term retention are built externally, with Object Storage as the durable hub and a SIEM as the correlation point.
Central Logging is a per-region, contract-level switch (administrator-gated) that lets integrated products forward logs for you; the dedicated-VMware estate is observed through vCenter 8.0 and vSAN, a separate domain reconciled only at the SIEM.

Important Terminology:

Telemetry plane: one of the four fixed-scope observability products (metrics, logs, audit, network flow), each with its own ingestion path and retention model.
Central Logging: a contract-level, per-region capability that lets integrated IONOS Cloud products forward their logs to the Logging Service on your behalf, surfaced in the managed Grafana.
Flow log: a per-resource rule emitting 5-tuple connection records with the firewall ACCEPT/REJECT verdict to a customer-owned Object Storage bucket, rotated every 10 minutes.
Fan-in: the enterprise aggregation pattern of forwarding every plane from every contract into one external SIEM for cross-contract correlation and long-term retention.

Learning Objectives