liveBook · Manning

WireMock

As explained in Logs and Telemetry

WireMock is a tool for mocking HTTP-based APIs and inspecting or controlling their requests and responses.

WireMock provides a local HTTP server for testing and inspecting event delivery. Configure it to respond to requests, validate details such as headers and basic-auth credentials, and return payloads. It is useful when a Fluent Bit output needs a controllable destination rather than a live external service. section 5.8

For a simple HTTP-output flow, start the supplied WireMock container, then send Fluent Bit traffic to its host, port, and URI. An HTTP output can post JSON to `127.0.0.1:8080/simple`, add a `fluentbit` header, and format timestamps as ISO 8601. WireMock makes the receiving endpoint available locally while that configuration is exercised. section 5.8

Listing 5.10 HTTP output example: http-output.conf
[SERVICE]
  flush 1
  log_level error

[INPUT]
  name http    
  listen 0.0.0.0
  port 9881
  tag http-in

[OUTPUT]
  match *
  name http     #1
  port 8080     #2
  host 127.0.0.1
  uri /simple                  #3
  format json               #4
  header fluentbit http         #5
  json_date_format iso8601    #6

Use this configuration as a minimal local flow: an HTTP input accepts traffic on port 9881, while the HTTP output forwards matching events as JSON to WireMock on port 8080. section 5.8

WireMock supports two complementary checks for OpenTelemetry output:

  • Retrieve mappings to inspect the configured WireMock behavior. section 5.10
  • Retrieve recorded requests to see what the OpenTelemetry output is receiving. section 5.10
  • Search returned request data for output URLs such as `/my/metrics`, `/my/logs`, and trace output paths to distinguish generated event types. section 5.10

OpenTelemetry output can send metrics, logs, and traces to WireMock on localhost port 8080 through separate URIs. Recorded requests expose a JSON response containing a Base64-packed Protobuf body; visible body elements can still confirm that the payload reflects the expected event content. section 5.10

Listing 5.12 OpenTelemetry output: otel-output.conf
[SERVICE]
    flush 1
    log_level info
    log_file  fluent-bit.log

[INPUT]
    name fluentbit_metrics
    tag node_metrics
    scrape_interval 300

[INPUT]
    name dummy
    tag dummy.log
[INPUT]     
    name event_type
    type  traces

#[OUTPUT]   #1
…name stdout
…match *

[OUTPUT]
    name opentelemetry      #2
    match  *
    host  localhost          #3
    port  8080
    metrics_uri /v1/metrics        #4
    logs_uri  /v1/logs
    traces_uri /v1/traces
    add_label app fluent-bit-demo    #5
    add_label client fluent-bit
    log_response_payload True                  #6

This output configuration directs all Fluent Bit events to localhost and separates metrics, logs, and traces by URI. It also enables response-payload logging for the OpenTelemetry output. section 5.10

Inspecting a local OpenTelemetry delivery

Start WireMock, run Fluent Bit with the OpenTelemetry output configuration, and use the WireMock requests operation in Postman. The returned HTTP response shows recorded event data, allowing the metrics, logs, and traces destinations to be checked without relying only on console output. section 5.10

How Logs and Telemetry covers it

How deep it goes
Explains startup, endpoint configuration, request retrieval, and payload inspection without detailing WireMock mapping syntax.
Examples
Uses a localhost `/simple` HTTP endpoint and recorded OpenTelemetry metrics, logs, and traces requests viewed in Postman.
What it assumes
Assumes ability to run a container, Fluent Bit configurations, and HTTP requests; supplies local startup scripts and configurations.
What you can do after
Diagnose/debug with it by inspecting locally recorded requests and validating output headers or basic-auth credentials.
How it connects
Connects WireMock with Fluent Bit, HTTP output, OpenTelemetry, Postman, JSON, Protobuf, and basic authentication.

Also explained in

Compare how 2 books explain WireMock →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Logs and Telemetry. The section links point to the parts of the book it draws on.