Logging Monitoring Failures in Axum with Mongodb

When building HTTP services in Rust with Axum, integrating MongoDB as the primary data store introduces specific observability risks if logging and monitoring are not explicitly instrumented. Without structured logs and explicit correlation of requests to database operations, failures become difficult to trace and may leave sensitive data paths unmonitored.

Axum does not provide built-in database logging; developers must explicitly log key events such as connection establishment, query execution, authentication failures, and write operations. If these logs are incomplete or inconsistent, monitoring tools cannot reliably detect anomalies like unauthorized data access patterns, unexpected query volumes, or authentication bypass attempts targeting MongoDB endpoints.

Incomplete logging can mask common attack patterns such as injection attempts or enumeration probes. For example, if failed authentication attempts against MongoDB are not recorded with sufficient context (source IP, username attempted, timestamp), security monitoring systems will not generate alerts for brute-force or credential-stuffing campaigns. Similarly, missing query-level logging prevents detection of overly broad read operations or changes to sensitive collections that could indicate malicious insider activity or compromised application logic.

Operational monitoring gaps also emerge when application-level metrics from Axum are not mapped to MongoDB performance indicators. Latency spikes or connection pool exhaustion in MongoDB may not surface in Axum logs if developers do not explicitly capture driver-level outcomes. This lack of visibility can delay incident response and allow issues such as denial-of-service via resource exhaustion to persist undetected.

Compliance mappings such as OWASP API Top 10’s Broken Object Level Authorization (BOLA) and Data Exposure categories rely on detailed audit trails. Without comprehensive logging of access patterns to specific MongoDB documents, auditors cannot verify that authorization checks are consistently enforced. This gap increases the likelihood of undetected IDOR vulnerabilities in production environments.

To address these risks, teams should implement structured logging that captures MongoDB operation metadata alongside Axum request context. This includes operation type, collection name, filter patterns (without sensitive values), outcome (success/failure), and timing. When integrated with monitoring systems, these logs enable detection of suspicious patterns such as repeated access to non-public endpoints or unexpected spikes in write operations.

Effective remediation centers on explicit instrumentation of MongoDB interactions within Axum handlers and middleware. The following practices and code examples illustrate how to implement robust logging and monitoring for MongoDB-backed services.

1. Structured Logging with Context

Use a structured logger such as tracing to emit logs that include request identifiers, user context (if available), and MongoDB operation details. This ensures each log line can be correlated across Axum and MongoDB layers.

use axum::{Extension, Json};
use mongodb::{Client, Collection};
use serde::{Deserialize, Serialize};
use tracing::{info, error};
use std::net::SocketAddr;

#[derive(Debug, Serialize, Deserialize)]
struct User {
    id: String,
    email: String,
}

async fn get_user(
    Extension(client): Extension,
    axum::extract::Path(user_id): axum::extract::Path,
) -> Result, (axum::http::StatusCode, String)> {
    let coll: Collection = client.database("appdb").collection("users");
    let id = user_id.to_string();
    
    info!(
        target: "db_ops",
        operation = "find_one",
        collection = "users",
        filter = ?serde_json::json!({ "_id": &id }),
        request_id = %uuid::Uuid::new_v4()
    );

    match coll.find_one(doc! { "_id": id }, None).await {
        Ok(Some(user)) => Ok(Json(user)),
        Ok(None) => {
            error!(target: "db_ops", operation = "find_one", error = "not_found", collection = "users");
            Err((axum::http::StatusCode::NOT_FOUND, "User not found".to_string()))
        }
        Err(e) => {
            error!(target: "db_ops", operation = "find_one", error = %e, collection = "users");
            Err((axum::http::StatusCode::INTERNAL_SERVER_ERROR, "Database error".to_string()))
        }
    }
}

2. Monitoring Connection and Query Outcomes

Instrument connection acquisition and query execution to surface latency and failure metrics. Capture success/failure status and timing for each MongoDB operation.

use mongodb::bson::doc;
use std::time::Instant;

async fn create_user(
    client: &Client,
    new_user: User,
) -> Result<(), mongodb::error::Error> {
    let coll: Collection = client.database("appdb").collection("users");
    let start = Instant::now();
    
    let result = coll.insert_one(new_user, None).await;
    
    let duration = start.elapsed();
    match &result {
        Ok(_) => {
            info!(
                target: "db_ops",
                operation = "insert_one",
                collection = "users",
                success = true,
                latency_ms = duration.as_millis()
            );
        }
        Err(e) => {
            error!(
                target: "db_ops",
                operation = "insert_one",
                collection = "users",
                success = false,
                error = %e,
                latency_ms = duration.as_millis()
            );
        }
    }
    result.map(|_| ())
}

3. Middleware for Request-Level Monitoring

Add Axum middleware to capture incoming request metadata and ensure every request produces at least one log entry tied to MongoDB activity. This provides a baseline for monitoring request volume and error rates.

use axum::{async_trait, extract::Extension};
use std::future::Future;
use tracing::Span;

pub struct MonitoringLayer;

impl axum::extract::FromRequest for MonitoringLayer
where
    S: Send + Sync,
{
    type Rejection = ();
    type Future = std::future::Ready>;

    fn from_request(req: axum::http::Request) -> Self::Future {
        let method = req.method().clone();
        let uri = req.uri().clone();
        info!(
            target: "requests",
            method = %method,
            uri = %uri,
            event = "request_start"
        );
        std::future::Ready(Ok(MonitoringLayer))
    }
}

// Usage in router setup:
// let app = Router::new()
//     .route("/users/:id", get(get_user))
//     .layer(Extension(client))
//     .layer(TowerLayer::new())
//     .into_make_service();

use mongodb::bson::oid::ObjectId;

async fn log_audit_event(
    user_id: &str,
    operation: &str,
    collection: &str,
    record_id: &ObjectId,
) {
    info!(
        target: "audit",
        user_id = user_id,
        operation = operation,
        collection = collection,
        record_id = %record_id,
        timestamp = chrono::Utc::now().to_rfc3339()
    );
}