11. Observability, Troubleshooting and Performance Analytics

Introduction and Context

Linux systems are rarely difficult to operate because a single command is unknown. They are difficult because failures emerge from interactions among applications, kernels, filesystems, networks, storage devices, virtual machines, containers, and human changes. A service may appear to be “slow” although its process is consuming little CPU; the actual constraint may be disk latency, memory reclaim, DNS resolution, lock contention, or a downstream dependency. Effective administration therefore requires more than monitoring whether a process is alive. It requires evidence that explains what the system is doing, why it is doing it, and how its behaviour changes over time.

Observability is the disciplined use of externally visible evidence to infer the internal state of a system. In Linux environments, this evidence is obtained from logs, time-series metrics, traces, kernel interfaces, process information, system calls, performance counters, and event-based instrumentation. Troubleshooting is the structured process of moving from a symptom to a verified cause and then to a safe corrective action. Performance analytics extends troubleshooting by establishing baselines, identifying bottlenecks, forecasting capacity, and evaluating whether an optimization produces a real improvement.

The distinction between monitoring and observability is important. Monitoring commonly answers predefined questions such as whether CPU utilization exceeds 90 percent or whether a service is down. Observability supports questions that were not anticipated when the system was instrumented, for example: which requests experience high latency only when a particular disk queue is saturated? Logs, metrics, and traces are complementary rather than interchangeable. A metric can reveal that latency has increased, a trace can identify the slow component of a request, and a log can explain the event that caused the component to fail.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain the relationship among logs, metrics, traces, events, and profiles.

2. Use journald, procfs, sysfs, and standard Linux utilities to form evidence-based hypotheses.

3. Apply a repeatable troubleshooting workflow rather than relying on guesswork.

4. Interpret CPU, memory, I/O, network, and scheduler measurements.

5. Describe the roles and limitations of strace, perf, and eBPF.

6. Establish performance baselines and distinguish saturation, errors, latency, and utilization.

7. Design practical observability and capacity-planning strategies.

8. Evaluate operational, security, ethical, and governance considerations in system instrumentation.

Observability as Evidence-Based Inference

A useful observability model has four related signals. Logs are timestamped records of discrete events, such as authentication failures, service state changes, kernel messages, or application errors. Metrics are numerical measurements collected over time, such as request rate, CPU time, memory consumption, filesystem capacity, and latency percentiles. Traces represent the path of a request across processes or services and show the duration of individual operations. Profiles describe where a program or system spends resources, for example in particular functions, system calls, or stack traces.

These signals have different costs and strengths. Logs preserve detail but can be voluminous and difficult to aggregate. Metrics are efficient for dashboards and alerting but may conceal individual outliers. Traces explain causality across distributed components, although trace collection and context propagation require design. Profiles provide statistical evidence about resource consumption, but they generally require specialized instrumentation and careful interpretation.

An observability system should preserve context. A timestamp must have reliable clock synchronization; a log should identify the host, service, severity, and correlation or request identifier; a metric should specify its unit, aggregation, and labels; and a trace should maintain a consistent request identity across components. Poorly designed labels can create high-cardinality metrics, overwhelming the monitoring system and increasing cost. Excessive logging can also consume storage, increase I/O, expose sensitive data, and make important events harder to find.

A practical analytical chain is:

Symptom → measurement → hypothesis → targeted experiment → verified cause → controlled remediation.

For example, “the web application is slow” is a symptom, not a diagnosis. Measurements may show increased p95 request latency, normal CPU utilization, elevated disk await time, and a rise in database query duration. The resulting hypothesis is that storage or database I/O is limiting request completion. A targeted experiment might compare latency while temporarily reducing a batch workload. If latency falls and the change is reproducible, the hypothesis gains support, but it should still be validated against application and database evidence.

A Troubleshooting Method for Linux Systems

Troubleshooting begins by defining the problem precisely. The investigator should record when the issue started, which users or workloads are affected, the affected hosts and services, the expected behaviour, and the business impact. A reproducible statement is more useful than a general complaint. “API p95 latency increased from 180 ms to 1.8 s after the 14:00 deployment, affecting requests that write files” is an actionable problem description.

The next step is to preserve evidence and establish scope. Check whether the problem affects one process, one host, one availability zone, or the entire service. Determine whether it is constant, periodic, load-dependent, or correlated with a change. Avoid immediately restarting a service or deleting files: such actions may remove evidence or alter the failure mode. If a service is in danger of exhausting resources, containment may be necessary, but the action and its time should be recorded.

A useful sequence is to examine the system from broad symptoms toward specific mechanisms:

• service and kernel events;
• load, CPU, memory, storage, and network indicators;
• process and thread behaviour;
• system calls and application-level operations;
• code-level profiles or kernel events.

The sequence is not rigid. A known kernel error may justify starting at the event level, while a reproducible application slowdown may be investigated with tracing. The principle is to use the least intrusive tool that can distinguish among the leading hypotheses.

Hypotheses should be explicit and testable. “The system is overloaded” is vague. “The request queue is growing because worker threads are blocked on filesystem writes” can be tested by examining queue length, thread states, write latency, and filesystem activity. A good experiment changes one relevant factor, has a predicted result, and includes a rollback plan.

Journald, Logs, and Event Correlation

On systems using systemd, `journalctl` is the primary interface to the system journal. It can filter by boot, time, unit, priority, kernel messages, or executable. Typical investigations include:

```bash

journalctl -b

journalctl -u nginx --since "30 minutes ago"

journalctl -p warning..alert

journalctl -k

journalctl -f

```

`journalctl -b` limits output to the current boot, while a previous boot can be selected with an appropriate boot identifier. Filtering by unit is usually more useful than searching an entire journal. Kernel messages may expose OOM kills, filesystem errors, device resets, thermal events, or network-driver problems. Logs should be correlated with metrics using a common time reference. A log saying that a process was killed is more meaningful when memory pressure and reclaim activity are examined at the same time.

Journald retention, forwarding, access control, and rate limiting are operational design concerns. A local journal may be volatile unless persistent storage is configured. Central collection improves continuity and correlation but creates privacy, availability, and security obligations. Structured logging is preferable to unsearchable prose. Sensitive values such as passwords, tokens, and unnecessary personal data should never be logged.

procfs and sysfs: Kernel State as an Operational Interface

The virtual filesystems `/proc` and `/sys` expose kernel and device information. They are not ordinary disk-backed files; their contents are generated by the kernel and may change while being read.

`/proc/loadavg` reports load averages and process information. Load average is not simply CPU utilization: it includes tasks runnable on the CPU and, on Linux, tasks in uninterruptible sleep, commonly associated with I/O. Consequently, high load with low CPU utilization may indicate blocked storage or another uninterruptible resource. `/proc/meminfo` provides detailed memory counters, including available memory, page cache, swap, and reclaim-related values. `/proc/stat` contains CPU time categories, and `/proc/interrupts` helps reveal interrupt distribution and possible imbalance. Per-process information appears under `/proc/<pid>`, including status, memory mappings, open file descriptors, file descriptors, and thread information.

Useful commands include:

```bash

cat /proc/loadavg

cat /proc/meminfo

cat /proc/pressure/cpu

cat /proc/pressure/memory

cat /proc/pressure/io

cat /proc/<pid>/status

ls -l /proc/<pid>/fd

```

Pressure Stall Information (PSI) measures the time that tasks are delayed because a resource is unavailable. CPU pressure indicates contention for CPU execution; memory pressure indicates delays related to memory access or reclaim; I/O pressure indicates delays caused by I/O. PSI complements utilization: a device can show moderate utilization while latency-sensitive tasks experience substantial stalls.

`/sys` represents devices, drivers, kernel subsystems, and tunable attributes. Examples include block-device queue information, network interface statistics, CPU frequency data, and hardware topology. Many files are readable by ordinary users, while writing to sysfs can change system behaviour and normally requires administrative privilege. Such changes should be documented and tested because a tuning parameter that helps one workload may harm another.

Metrics and Performance Models

Performance analysis becomes more reliable when measurements are grouped into four categories: latency, traffic, errors, and saturation. Latency measures time to complete an operation. Traffic measures demand, such as requests per second or bytes per second. Errors measure unsuccessful or abnormal outcomes. Saturation measures queued or delayed work. Utilization is useful, but it is not equivalent to saturation: a CPU at 70 percent utilization may still produce unacceptable latency if workload bursts and scheduling priorities create queues.

Percentiles are often more informative than averages. Mean latency can remain stable while a small but important group of requests experiences severe delays. The p95 is the value below which 95 percent of observations fall; p99 describes a more demanding tail. Percentiles must be calculated over suitable windows and with adequate sample counts. Aggregating already-aggregated percentiles incorrectly can produce misleading results.

Little’s Law provides a useful relationship for stable systems:

L = λW

where L is the average number of items in the system, λ is throughput, and W is average time in the system. If a queue contains 200 requests and throughput is 100 requests per second, the average residence time is approximately two seconds, assuming the system is stable and the measurements refer to the same boundary. This relationship helps connect queue growth, throughput, and latency, but it does not identify the cause of delay.

A baseline should describe normal behaviour across representative time periods and workload levels. It should include throughput, latency distributions, resource utilization, error rates, and important saturation indicators. Baselines should account for seasonality, scheduled jobs, deployments, and traffic composition. A single “normal” value is rarely adequate for a production system.

CPU, Memory, Storage, and Network Analysis

CPU investigation should distinguish user time, system time, idle time, I/O wait, steal time in virtualized environments, and scheduler pressure. High user time may indicate computational demand, while high system time may indicate intensive kernel operations, networking, or system-call activity. Steal time suggests that a virtual machine is waiting for the hypervisor to provide CPU. Tools such as `vmstat`, `mpstat`, `pidstat`, and `top` provide different levels of detail.

A high CPU percentage for a process does not automatically imply inefficient code. The process may be performing necessary work at the offered load. Optimization requires identifying the hot path and relating it to an objective such as latency, throughput, or cost. CPU affinity and NUMA placement can matter for high-performance systems, but changing them without topology and workload evidence can reduce performance.

Memory analysis must distinguish resident memory, virtual address space, page cache, anonymous memory, and shared mappings. Linux uses available memory for caching, so low free memory alone is not evidence of a problem. More meaningful indicators include reclaim activity, major page faults, swap-in and swap-out, allocation failures, PSI memory pressure, and the OOM killer. The command `dmesg` or `journalctl -k` may reveal that a process was terminated by the out-of-memory mechanism. Container limits can cause an individual workload to be killed even when the host has free memory.

Storage performance involves throughput, operations per second, latency, queue depth, filesystem behaviour, and device characteristics. `iostat`, `pidstat -d`, `iotop` where available, and block-layer tracing can identify whether a process is issuing reads or writes and whether requests are waiting. A full filesystem and an exhausted inode table are separate conditions. `df -h` reports space, while `df -i` reports inode usage. Files deleted while still open continue consuming space until the process closes the file; such cases can be investigated through `/proc/<pid>/fd`.

Network analysis considers packet rate, bandwidth, retransmissions, drops, errors, connection queues, DNS latency, and application response time. `ss` displays socket state and queues, while interface counters can be examined with `ip -s link`. A service can have low bandwidth utilization yet suffer from connection exhaustion or packet loss. Network measurements should be made at both endpoints when possible.

strace: Observing System-Call Behaviour

`strace` records system calls and signals made by a process. It is particularly useful when an application appears blocked, repeatedly fails to access a file, or spends excessive time in a kernel interface. For example:

```bash

strace -f -tt -T -p <pid>

strace -c -p <pid>

strace -e trace=file,network -p <pid>

```

The `-T` option reports time spent in each call, `-f` follows threads and child processes, and `-c` summarizes calls. Filtering reduces noise. A trace showing repeated `stat()` calls, long `connect()` calls, or frequent `futex()` operations can direct investigation toward metadata access, network dependencies, or thread synchronization.

Strace is not a complete application profiler. It adds overhead, may alter timing, and observes system-call boundaries rather than internal functions. Attaching to sensitive processes also has security implications. It should normally be used briefly, with authorization, and preferably in a controlled environment for high-throughput workloads.

perf and Statistical Profiling

`perf` interfaces with Linux performance monitoring facilities. It can count events, sample call stacks, and inspect scheduler behaviour. Examples include:

```bash

perf stat -p <pid> sleep 10

perf record -F 99 -g -p <pid> -- sleep 30

perf report

perf top

```

`perf stat` can report cycles, instructions, cache references, cache misses, context switches, and migrations, depending on processor and kernel support. `perf record` samples execution and, with call-graph collection, helps identify functions associated with CPU time. Sampling is statistical: a function appearing frequently is evidence of a hot region, not proof that every invocation is expensive.

Interpretation requires caution. Hardware counters differ across processor models; multiplexing can reduce precision; missing symbols make call graphs difficult to read; and compiler optimization can change stack visibility. A profile should be compared with workload, version, and configuration information. Microarchitectural optimization is valuable only when it improves a meaningful service-level objective.

eBPF and Low-Overhead Dynamic Observability

eBPF allows verified programs to run in response to selected kernel or tracing events. It supports observability of system calls, scheduler activity, network paths, block I/O, and application probes. Tools such as `bpftrace`, BCC utilities, and higher-level platforms use eBPF to collect latency histograms, process events, and stack traces without modifying the application binary in many cases.

A conceptual example is a histogram of block-I/O completion latency or a count of failed `openat` calls by process. Rather than collecting every event as a detailed log, eBPF can aggregate observations in the kernel and export summaries. This reduces data volume and makes it practical to investigate short-lived or system-wide phenomena.

The technology has boundaries. Kernel configuration, permissions, verifier rules, architecture, and tool compatibility affect availability. Poorly designed probes can consume CPU, generate excessive data, or expose sensitive information. eBPF programs should be reviewed, version-controlled, restricted by privilege, and tested before broad deployment. The ability to observe a process does not remove the need for consent, access control, and appropriate data retention.

From Diagnosis to Capacity Planning

Capacity planning asks whether a system can sustain expected demand with acceptable performance and resilience. It begins with a demand model: request rate, data growth, concurrency, batch schedules, and workload mix. Resource models then relate demand to CPU, memory, storage, network, and dependency capacity. The plan should include headroom for bursts, failures, maintenance, and growth.

A simple method is to identify the limiting resource under representative load, measure its sustainable throughput, and compare it with forecast demand. If a service sustains 800 requests per second at its latency objective and projected peak demand is 600 requests per second, the apparent headroom is 25 percent relative to capacity. However, this estimate is incomplete if a single node fails, if traffic is unevenly distributed, or if downstream storage saturates first.

Capacity decisions should be validated with load testing, production observations, and failure scenarios. Vertical scaling, horizontal scaling, caching, batching, asynchronous processing, query optimization, and workload scheduling have different cost and reliability implications. An optimization that reduces CPU but increases memory pressure may simply move the bottleneck.

Illustrative Case Study: Intermittent Latency in a Linux API Cluster

Background

A university research service runs a Linux-based API cluster. Users report that file-submission requests occasionally take more than ten seconds, although average response time remains below one second. The service uses multiple application workers, a relational database, and local temporary storage.

Situation and Initial Evidence

The operations team observes an increase in p99 latency during scheduled nightly data processing. CPU utilization is approximately 55 percent, so an initial assumption is that the application is not CPU-bound. The service logs show request timeouts but no consistent application exception. `journalctl -u api` reveals no service crashes. The host’s load average rises sharply, while `/proc/pressure/cpu` remains modest and `/proc/pressure/io` increases.

Analysis

`iostat` shows elevated device latency and queue depth during the data-processing window. `pidstat -d` identifies a batch process issuing large numbers of writes. Application traces show that slow requests spend most of their time in temporary-file operations. A short `strace` sample from a worker confirms long waits in file-related system calls, but it does not explain the entire system behaviour. An eBPF block-I/O latency histogram shows that the tail of write completion latency expands when the batch process is active.

The evidence supports an I/O saturation hypothesis rather than a CPU shortage. The team also verifies that the database is not the primary source of delay and that network retransmissions are normal. The causal chain is: batch writes increase device queueing; temporary-file operations wait longer; API workers remain occupied; request queues grow; tail latency increases.

Approach and Solution

The batch job is moved to a controlled schedule and assigned an appropriate I/O priority. Temporary files are redirected to a separate device with adequate capacity. The API is changed to reject oversized submissions early and to process nonessential post-upload work asynchronously. Dashboards are updated to include p95 and p99 latency, block-device latency, queue depth, I/O PSI, batch-job activity, and request timeout rate.

Outcome

During subsequent processing windows, API tail latency remains within its service objective, while the batch completes within an acceptable time. The solution does not depend on reducing CPU utilization; it removes contention at the actual bottleneck and improves workload isolation.

Learning Points

The case demonstrates why utilization alone is insufficient, why load average must be interpreted with resource-specific evidence, and why traces, system-call observations, and block-layer measurements are stronger when correlated. It also illustrates that performance optimization is often a scheduling and architecture problem rather than a search for a faster function.

Operational Risks, Governance, and Professional Practice

Observability data can contain command arguments, usernames, file paths, network addresses, request bodies, or identifiers. Collection should follow data minimization, purpose limitation, retention policies, and access control. Production tracing may expose customer information; system-call tracing may reveal secrets passed through arguments or environment variables. Administrative access to `/proc`, perf events, and eBPF facilities should be governed because powerful instrumentation can become a channel for information disclosure or system modification.

Common mistakes include changing many variables simultaneously, treating correlation as causation, relying on averages, ignoring time synchronization, collecting data without a retention plan, and interpreting a single command output without workload context. Another frequent error is optimizing a component that is not on the critical path. Post-incident reports should distinguish evidence from speculation and should focus on system improvements rather than individual blame.

Best practice is to maintain a service catalogue, define service-level objectives, instrument important boundaries, standardize labels and timestamps, document baselines, and rehearse diagnostic procedures. Dashboards should support decisions rather than display every available metric. Alerts should be actionable, tied to user impact or imminent risk, and designed to avoid fatigue. Every major remediation should be evaluated after deployment to determine whether the intended objective was achieved.

Current Developments

Modern Linux observability increasingly combines OpenTelemetry-compatible traces and metrics with logs, continuous profiling, and eBPF-based infrastructure visibility. Projects and commercial platforms are improving correlation among application spans, kernel events, container metadata, and cloud resources. Continuous profiling is becoming more practical for identifying recurring CPU and memory costs without waiting for an incident.

At the same time, observability systems are becoming distributed systems in their own right. Sampling strategies, cardinality control, storage cost, privacy, and data sovereignty require architectural decisions. Automated anomaly detection and machine-learning-assisted root-cause suggestions can prioritize evidence, but they do not replace causal reasoning. Automated remediation should be limited by safeguards, approval rules, rollback mechanisms, and clear accountability.

Chapter Summary

Observability uses logs, metrics, traces, profiles, and kernel evidence to infer system behaviour. Effective troubleshooting moves from a precise symptom to measurements, explicit hypotheses, targeted experiments, verified causes, and controlled remediation. `journalctl` provides structured access to system and service events; procfs and sysfs expose live kernel and device state; `strace` reveals system-call behaviour; `perf` supports statistical and hardware-assisted profiling; and eBPF enables efficient dynamic observation across kernel and application boundaries.

Performance analysis should consider latency, traffic, errors, saturation, queues, and resource pressure rather than utilization alone. CPU, memory, storage, and network investigations require different evidence and should be correlated over time. Baselines support anomaly detection and capacity planning, while Little’s Law connects throughput, residence time, and concurrency. Professional practice also requires privacy protection, access control, data minimization, careful experimentation, and governance of automated tools.

Key Terms

Observability: The ability to infer internal system state from externally collected evidence.

Monitoring: The collection and evaluation of predefined measurements and conditions.

Log: A timestamped record of a discrete system or application event.

Metric: A numerical measurement observed over time.

Trace: A representation of a request’s path and timing across components.

Profile: Statistical evidence about where a program or system spends resources.

Journald: The systemd service responsible for collecting and managing journal records.

procfs: A virtual filesystem exposing process and kernel state through `/proc`.

sysfs: A virtual filesystem representing devices, drivers, and kernel subsystems.

Pressure Stall Information: Kernel measurements of time tasks are delayed by resource contention.

Latency: The time required to complete an operation.

Saturation: The condition in which demand causes queues, contention, or resource-related delay.

Percentile: A statistical boundary below which a stated proportion of observations falls.

System call: An interface through which a user-space process requests kernel services.

strace: A Linux utility for observing system calls and signals.

perf: A Linux performance-analysis facility for counters, sampling, and profiling.

eBPF: A mechanism for safely executing verified event-driven programs in the kernel.

Baseline: A documented representation of normal system behaviour under defined conditions.

Little’s Law: The relationship between average population, throughput, and residence time, expressed as L = λW.

Cardinality: The number of distinct values or combinations represented by a metric label set.

Review Questions

Short Answer Questions

1. How do logs, metrics, and traces differ in the evidence they provide?

2. Why can a high load average coexist with low CPU utilization on Linux?

3. What information can be obtained from `/proc/meminfo` and PSI files?

4. State two uses and one limitation of `strace`.

5. Why are latency percentiles often more useful than average latency?

Long Answer Questions

1. Explain a structured troubleshooting workflow from symptom definition to verified remediation, using Linux tools in your explanation.

2. Compare the roles of `journalctl`, procfs, sysfs, `strace`, `perf`, and eBPF in performance investigation.

3. Discuss how CPU, memory, storage, and network bottlenecks can be distinguished using measurements and correlations.

4. Explain how baselines, Little’s Law, and saturation indicators contribute to capacity planning.

5. Discuss privacy, access control, data retention, and professional responsibilities in observability engineering.

Analytical / Application Questions

1. A server has 75 percent CPU utilization, a high load average, low CPU PSI, and rising I/O PSI. Which hypotheses should be tested first, and which commands or interfaces would provide evidence?

2. An application’s average latency is unchanged but its p99 latency has increased fivefold after a deployment. Design an investigation using logs, traces, metrics, and at least one low-level Linux tool.

3. A batch process and an interactive API share a storage device. Propose a measurement-driven strategy to determine whether workload isolation, scheduling changes, or hardware expansion is the most appropriate remedy.

22. Multiple Choice Questions with Answers

Question 1

Which observation most strongly suggests that a Linux system is experiencing I/O-related contention rather than CPU contention?

A. High user CPU time and low run-queue length

B. Low CPU pressure with elevated I/O pressure and storage queue depth

C. Low load average with increased available memory

D. High instruction-retirement rate with low device latency

Correct Answer: B. Low CPU pressure with elevated I/O pressure and storage queue depth

Question 2

What is the principal value of combining a request trace with system metrics?

A. The trace eliminates the need for logs

B. Metrics identify exact source-code lines without profiling

C. The trace can locate request delay while metrics provide system-wide context

D. Metrics and traces always measure the same event

Correct Answer: C. The trace can locate request delay while metrics provide system-wide context

Question 3

Which command is most directly suited to displaying logs for a particular systemd service during a recent time interval?

A. journalctl -u service --since "30 minutes ago"

B. perf report -u service

C. strace -u service --since "30 minutes ago"

D. df -u service --since "30 minutes ago"

Correct Answer: A. journalctl -u service --since "30 minutes ago"

Question 4

A process has a large virtual address space but moderate resident memory. Which conclusion is most appropriate?

A. The process definitely has a memory leak

B. The process is necessarily swapping heavily

C. Virtual address space alone does not establish physical-memory pressure

D. The process has exhausted the inode table

Correct Answer: C. Virtual address space alone does not establish physical-memory pressure

Question 5

What does the relationship L = λW express?

A. CPU utilization equals memory pressure multiplied by latency

B. Average items in a system equal throughput multiplied by average time in the system

C. Storage latency equals queue depth divided by bandwidth in every workload

D. Error rate equals request rate multiplied by saturation

Correct Answer: B. Average items in a system equal throughput multiplied by average time in the system

Question 6

Which `strace` option is particularly useful for reporting the time spent in individual system calls?

A. -T

B. -c

C. -f

D. -p

Correct Answer: A. -T

Question 7

What is a major purpose of `perf record` with call-graph collection?

A. To configure persistent journald storage

B. To sample execution and help identify CPU hot paths

C. To display filesystem free space

D. To change process scheduling priority automatically

Correct Answer: B. To sample execution and help identify CPU hot paths

Question 8

Why can excessive metric label cardinality be harmful?

A. It prevents all logs from being written to disk

B. It can greatly increase storage, processing, and query costs

C. It disables kernel system calls

D. It guarantees inaccurate CPU counters

Correct Answer: B. It can greatly increase storage, processing, and query costs

Question 9

In the case study, why did reducing CPU utilization not solve the API latency problem?

A. The actual bottleneck was storage contention caused by batch writes

B. The API was waiting for DNS responses exclusively

C. The host had no active application workers

D. The database had stopped accepting all connections

Correct Answer: A. The actual bottleneck was storage contention caused by batch writes

Question 10

Which practice is most appropriate when deploying eBPF instrumentation in production?

A. Collect every possible event permanently without filtering

B. Run probes without authorization because they are read-only

C. Review privileges, limit collection, test overhead, and protect collected data

D. Replace all application-level instrumentation with kernel probes

Correct Answer: C. Review privileges, limit collection, test overhead, and protect collected data