litewave-logger 0.2.0__tar.gz → 0.3.0__tar.gz

{litewave_logger-0.2.0 → litewave_logger-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: litewave_logger
-Version: 0.2.0
+Version: 0.3.0
 Summary: A lightweight logging library with context carry forward
 Author: Litewave
 Author-email: Sonu Sudhakaran <sonu@litewave.ai>
@@ -18,10 +18,12 @@ This module provides a centralized and consistent logging solution for Litewave
 ## Features
 
 - **Centralized Logging**: A single module to configure and manage logging across all services.
+- **JSON Logging**: All logs are formatted as JSON for easy parsing and integration with log aggregation systems.
 - **Request ID Propagation**: Automatically injects a `request-id` into all log messages.
-- **FastAPI Integration**: Middleware for FastAPI to handle `request-id` for incoming HTTP requests.
-- **Celery Integration**: Signal handlers to propagate the `request-id` to Celery tasks.
+- **FastAPI Integration**: Middleware for FastAPI to handle `request-id` for incoming HTTP requests and adds it to response headers.
+- **Celery Integration**: Signal handlers to propagate the `request-id` to Celery tasks automatically.
 - **Requests Library Patching**: Automatically injects the `request-id` into outgoing HTTP requests made with the `requests` library.
+- **Endpoint Exclusion**: Configure endpoints that should not be logged (e.g., health checks, metrics).
 
 ## Installation
 
@@ -37,7 +39,8 @@ To use the `litewave_logger` in your service, follow these steps:
     ```python
     from litewave_logger import setup_logging
 
-    setup_logging()
+    # Optionally exclude endpoints from logging (e.g., health checks, metrics)
+    setup_logging(excluded_endpoints=['/health', '/metrics'])
     ```
 
 2.  **Add the FastAPI middleware**: If your service is a FastAPI application, add the `RequestIdMiddleware` to your FastAPI app.
@@ -58,10 +61,11 @@ To use the `litewave_logger` in your service, follow these steps:
     patch_requests()
     ```
 
-4.  **Connect Celery signals**: If your service uses Celery, you need to import the Celery signal handlers to ensure they are registered. You don't need to call them directly.
+4.  **Connect Celery signals**: If your service uses Celery, you need to import the Celery module to ensure the signal handlers are registered. The signal handlers are automatically connected via decorators, so you don't need to call them directly.
 
     ```python
-    from litewave_logger.celery import propagate_request_id_to_celery, clear_request_id_after_celery
+    # Just import the module - signal handlers are automatically registered
+    import litewave_logger.celery
     ```
 
 ### Example
@@ -74,11 +78,11 @@ from litewave_logger import setup_logging
 from litewave_logger.middleware import RequestIdMiddleware
 from litewave_logger.requests import patch_requests
 
-# These imports are needed to register the signal handlers
-from litewave_logger.celery import propagate_request_id_to_celery, clear_request_id_after_celery
+# Import Celery module to register signal handlers (if using Celery)
+import litewave_logger.celery
 
-# 1. Initialize logging
-setup_logging()
+# 1. Initialize logging (optionally exclude endpoints)
+setup_logging(excluded_endpoints=['/health', '/metrics'])
 
 # 2. Patch requests library
 patch_requests()
@@ -90,3 +94,31 @@ app.add_middleware(RequestIdMiddleware)
 
 # Your application code here...
 ```
+
+## How It Works
+
+### Request ID Flow
+
+1. **Incoming HTTP Request**: The `RequestIdMiddleware` checks for an `X-Request-ID` header. If present, it uses that value; otherwise, it generates a new UUID.
+2. **Context Variable**: The request ID is stored in a context variable (`request_id_var`) that is automatically maintained across async operations.
+3. **Logging**: All log messages automatically include the request ID via the `RequestIdFilter`.
+4. **Outgoing Requests**: When using the `requests` library, the request ID is automatically injected as the `X-Request-ID` header.
+5. **Response Headers**: The request ID is added to the response headers as `X-Request-ID`.
+6. **Celery Tasks**: When a Celery task is published, the request ID is automatically included in the task headers and propagated to the worker process.
+
+### Log Format
+
+All logs are formatted as JSON with the following structure:
+
+```json
+{
+  "timestamp": "2024-01-01 12:00:00",
+  "level": "INFO",
+  "request_id": "550e8400-e29b-41d4-a716-446655440000",
+  "path": "/api/users",
+  "method": "GET",
+  "message": "request received",
+  "status_code": 200,
+  "error": null
+}
+```

{litewave_logger-0.2.0 → litewave_logger-0.3.0}/README.md

@@ -5,10 +5,12 @@ This module provides a centralized and consistent logging solution for Litewave
 ## Features
 
 - **Centralized Logging**: A single module to configure and manage logging across all services.
+- **JSON Logging**: All logs are formatted as JSON for easy parsing and integration with log aggregation systems.
 - **Request ID Propagation**: Automatically injects a `request-id` into all log messages.
-- **FastAPI Integration**: Middleware for FastAPI to handle `request-id` for incoming HTTP requests.
-- **Celery Integration**: Signal handlers to propagate the `request-id` to Celery tasks.
+- **FastAPI Integration**: Middleware for FastAPI to handle `request-id` for incoming HTTP requests and adds it to response headers.
+- **Celery Integration**: Signal handlers to propagate the `request-id` to Celery tasks automatically.
 - **Requests Library Patching**: Automatically injects the `request-id` into outgoing HTTP requests made with the `requests` library.
+- **Endpoint Exclusion**: Configure endpoints that should not be logged (e.g., health checks, metrics).
 
 ## Installation
 
@@ -24,7 +26,8 @@ To use the `litewave_logger` in your service, follow these steps:
     ```python
     from litewave_logger import setup_logging
 
-    setup_logging()
+    # Optionally exclude endpoints from logging (e.g., health checks, metrics)
+    setup_logging(excluded_endpoints=['/health', '/metrics'])
     ```
 
 2.  **Add the FastAPI middleware**: If your service is a FastAPI application, add the `RequestIdMiddleware` to your FastAPI app.
@@ -45,10 +48,11 @@ To use the `litewave_logger` in your service, follow these steps:
     patch_requests()
     ```
 
-4.  **Connect Celery signals**: If your service uses Celery, you need to import the Celery signal handlers to ensure they are registered. You don't need to call them directly.
+4.  **Connect Celery signals**: If your service uses Celery, you need to import the Celery module to ensure the signal handlers are registered. The signal handlers are automatically connected via decorators, so you don't need to call them directly.
 
     ```python
-    from litewave_logger.celery import propagate_request_id_to_celery, clear_request_id_after_celery
+    # Just import the module - signal handlers are automatically registered
+    import litewave_logger.celery
     ```
 
 ### Example
@@ -61,11 +65,11 @@ from litewave_logger import setup_logging
 from litewave_logger.middleware import RequestIdMiddleware
 from litewave_logger.requests import patch_requests
 
-# These imports are needed to register the signal handlers
-from litewave_logger.celery import propagate_request_id_to_celery, clear_request_id_after_celery
+# Import Celery module to register signal handlers (if using Celery)
+import litewave_logger.celery
 
-# 1. Initialize logging
-setup_logging()
+# 1. Initialize logging (optionally exclude endpoints)
+setup_logging(excluded_endpoints=['/health', '/metrics'])
 
 # 2. Patch requests library
 patch_requests()
@@ -77,3 +81,31 @@ app.add_middleware(RequestIdMiddleware)
 
 # Your application code here...
 ```
+
+## How It Works
+
+### Request ID Flow
+
+1. **Incoming HTTP Request**: The `RequestIdMiddleware` checks for an `X-Request-ID` header. If present, it uses that value; otherwise, it generates a new UUID.
+2. **Context Variable**: The request ID is stored in a context variable (`request_id_var`) that is automatically maintained across async operations.
+3. **Logging**: All log messages automatically include the request ID via the `RequestIdFilter`.
+4. **Outgoing Requests**: When using the `requests` library, the request ID is automatically injected as the `X-Request-ID` header.
+5. **Response Headers**: The request ID is added to the response headers as `X-Request-ID`.
+6. **Celery Tasks**: When a Celery task is published, the request ID is automatically included in the task headers and propagated to the worker process.
+
+### Log Format
+
+All logs are formatted as JSON with the following structure:
+
+```json
+{
+  "timestamp": "2024-01-01 12:00:00",
+  "level": "INFO",
+  "request_id": "550e8400-e29b-41d4-a716-446655440000",
+  "path": "/api/users",
+  "method": "GET",
+  "message": "request received",
+  "status_code": 200,
+  "error": null
+}
+```

{litewave_logger-0.2.0 → litewave_logger-0.3.0}/litewave_logger/__init__.py

@@ -8,6 +8,9 @@ from contextvars import ContextVar
 # Magically, this is maintained across multiple requests without it getting mixed up.
 request_id_var = ContextVar("request_id", default=None)
 
+# List of endpoints that should not be logged
+_excluded_endpoints = []
+
 
 class RequestIdFilter(logging.Filter):
     """
@@ -35,11 +38,20 @@ class JsonLogFormatter(logging.Formatter):
         }
         return json.dumps(log_object)
 
-def setup_logging():
+def setup_logging(excluded_endpoints=[]):
     """
     Configures the logging for the application.
     Uses a JSON formatter and adds the RequestIdFilter.
+
+    Args:
+        excluded_endpoints: List of endpoint paths that should not be logged.
+                          For example: ['/health', '/metrics']
+                          Defaults to None (empty list).
     """
+    global _excluded_endpoints
+
+    _excluded_endpoints = excluded_endpoints
+
     logger = logging.getLogger()
     logger.setLevel(logging.INFO)
 
@@ -57,4 +69,10 @@ def setup_logging():
 
     return logger
 
-__all__ = ["setup_logging", "request_id_var", "RequestIdFilter"]
+def get_excluded_endpoints():
+    """
+    Returns the list of excluded endpoints.
+    """
+    return _excluded_endpoints
+
+__all__ = ["setup_logging", "request_id_var", "RequestIdFilter", "get_excluded_endpoints"]

{litewave_logger-0.2.0 → litewave_logger-0.3.0}/litewave_logger/middleware.py

@@ -5,7 +5,7 @@ from datetime import datetime
 from starlette.middleware.base import BaseHTTPMiddleware
 from starlette.requests import Request
 
-from . import request_id_var
+from . import request_id_var, get_excluded_endpoints
 
 logger = logging.getLogger(__name__)
 RequestIdHeader = "X-Request-ID"
@@ -35,7 +35,12 @@ class RequestIdMiddleware(BaseHTTPMiddleware):
         # Set request ID in context
         request_id_var.set(request_id)
 
-        logger.info("request received", extra={"method": method, "path": path})
+        # Check if this endpoint should be excluded from logging
+        excluded_endpoints = get_excluded_endpoints()
+        should_log = path not in excluded_endpoints
+
+        if should_log:
+            logger.info("request received", extra={"method": method, "path": path})
 
         try:
             # Process the request
@@ -44,13 +49,13 @@ class RequestIdMiddleware(BaseHTTPMiddleware):
             # Add request ID to response headers
             response.headers[RequestIdHeader] = request_id
 
-            # Log response details
-            logger.info("response sent", extra={"status_code": response.status_code})
+            # Log response details only if endpoint is not excluded
+            if should_log:
+                logger.info("response sent", extra={"status_code": response.status_code})
 
             return response
 
         except Exception as e:
-            # Log error details
             logger.error("request failed", extra={"method": method, "path": path, "error": str(e)})
 
             # Re-raise the exception

{litewave_logger-0.2.0 → litewave_logger-0.3.0}/litewave_logger.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: litewave_logger
-Version: 0.2.0
+Version: 0.3.0
 Summary: A lightweight logging library with context carry forward
 Author: Litewave
 Author-email: Sonu Sudhakaran <sonu@litewave.ai>
@@ -18,10 +18,12 @@ This module provides a centralized and consistent logging solution for Litewave
 ## Features
 
 - **Centralized Logging**: A single module to configure and manage logging across all services.
+- **JSON Logging**: All logs are formatted as JSON for easy parsing and integration with log aggregation systems.
 - **Request ID Propagation**: Automatically injects a `request-id` into all log messages.
-- **FastAPI Integration**: Middleware for FastAPI to handle `request-id` for incoming HTTP requests.
-- **Celery Integration**: Signal handlers to propagate the `request-id` to Celery tasks.
+- **FastAPI Integration**: Middleware for FastAPI to handle `request-id` for incoming HTTP requests and adds it to response headers.
+- **Celery Integration**: Signal handlers to propagate the `request-id` to Celery tasks automatically.
 - **Requests Library Patching**: Automatically injects the `request-id` into outgoing HTTP requests made with the `requests` library.
+- **Endpoint Exclusion**: Configure endpoints that should not be logged (e.g., health checks, metrics).
 
 ## Installation
 
@@ -37,7 +39,8 @@ To use the `litewave_logger` in your service, follow these steps:
     ```python
     from litewave_logger import setup_logging
 
-    setup_logging()
+    # Optionally exclude endpoints from logging (e.g., health checks, metrics)
+    setup_logging(excluded_endpoints=['/health', '/metrics'])
     ```
 
 2.  **Add the FastAPI middleware**: If your service is a FastAPI application, add the `RequestIdMiddleware` to your FastAPI app.
@@ -58,10 +61,11 @@ To use the `litewave_logger` in your service, follow these steps:
     patch_requests()
     ```
 
-4.  **Connect Celery signals**: If your service uses Celery, you need to import the Celery signal handlers to ensure they are registered. You don't need to call them directly.
+4.  **Connect Celery signals**: If your service uses Celery, you need to import the Celery module to ensure the signal handlers are registered. The signal handlers are automatically connected via decorators, so you don't need to call them directly.
 
     ```python
-    from litewave_logger.celery import propagate_request_id_to_celery, clear_request_id_after_celery
+    # Just import the module - signal handlers are automatically registered
+    import litewave_logger.celery
     ```
 
 ### Example
@@ -74,11 +78,11 @@ from litewave_logger import setup_logging
 from litewave_logger.middleware import RequestIdMiddleware
 from litewave_logger.requests import patch_requests
 
-# These imports are needed to register the signal handlers
-from litewave_logger.celery import propagate_request_id_to_celery, clear_request_id_after_celery
+# Import Celery module to register signal handlers (if using Celery)
+import litewave_logger.celery
 
-# 1. Initialize logging
-setup_logging()
+# 1. Initialize logging (optionally exclude endpoints)
+setup_logging(excluded_endpoints=['/health', '/metrics'])
 
 # 2. Patch requests library
 patch_requests()
@@ -90,3 +94,31 @@ app.add_middleware(RequestIdMiddleware)
 
 # Your application code here...
 ```
+
+## How It Works
+
+### Request ID Flow
+
+1. **Incoming HTTP Request**: The `RequestIdMiddleware` checks for an `X-Request-ID` header. If present, it uses that value; otherwise, it generates a new UUID.
+2. **Context Variable**: The request ID is stored in a context variable (`request_id_var`) that is automatically maintained across async operations.
+3. **Logging**: All log messages automatically include the request ID via the `RequestIdFilter`.
+4. **Outgoing Requests**: When using the `requests` library, the request ID is automatically injected as the `X-Request-ID` header.
+5. **Response Headers**: The request ID is added to the response headers as `X-Request-ID`.
+6. **Celery Tasks**: When a Celery task is published, the request ID is automatically included in the task headers and propagated to the worker process.
+
+### Log Format
+
+All logs are formatted as JSON with the following structure:
+
+```json
+{
+  "timestamp": "2024-01-01 12:00:00",
+  "level": "INFO",
+  "request_id": "550e8400-e29b-41d4-a716-446655440000",
+  "path": "/api/users",
+  "method": "GET",
+  "message": "request received",
+  "status_code": 200,
+  "error": null
+}
+```

{litewave_logger-0.2.0 → litewave_logger-0.3.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "litewave_logger"
-version = "0.2.0"
+version = "0.3.0"
 description = "A lightweight logging library with context carry forward"
 authors = [{name = "Sonu Sudhakaran", email = "sonu@litewave.ai"}]
 dependencies = [

{litewave_logger-0.2.0 → litewave_logger-0.3.0}/setup.py

@@ -2,7 +2,7 @@ from setuptools import setup, find_packages
 
 setup(
     name="litewave_logger",
-    version="0.2.0",
+    version="0.3.0",
     description="A centralized logging module for Litewave services.",
     author="Litewave",
     packages=find_packages(),