Skip to main content

Inventory Device Ipping

RetrieveThe inventory device IP configurationping detailsAPI endpoint provides functionality to retrieve IP ping information for specificdevices inventoryin devices.your inventory. This endpoint allows you to monitor network connectivity status and track ping metrics for managed devices, helping with network diagnostics and device health monitoring.

Base URL: https://control.zequenze.com/api/v1

Authentication: All endpoints require a Bearer token:

Authorization: Bearer <your-api-token>

Overview

The inventory device IP ping API is designed for network administrators and IT teams who need to monitor and track the network connectivity status of devices in their managed inventory. This endpoint provides detailed ping information including response times, packet loss statistics, and connectivity status for specific devices.

Common use cases include:

    Monitoring network health across your device inventory Troubleshooting connectivity issues for specific devices Generating network performance reports Setting up automated network monitoring workflows Tracking historical ping performance data

    This endpoint works as part of the broader inventory management system, allowing you to correlate device information with network performance metrics. The ping data can be used to identify network bottlenecks, plan maintenance windows, and ensure optimal device connectivity.

    Endpoints

    GET /inventory_device_ipping/{id}/

    Description: Retrieves thedetailed IP configuration and addressingping information for a specific inventorydevice in your inventory. This endpoint returns comprehensive connectivity metrics including ping response times, packet loss statistics, success rates, and historical ping data for the specified device.

    Use Cases:

      Monitor real-time network connectivity for critical infrastructure devices Troubleshoot connectivity issues by reviewing ping history and statistics Generate network performance reports for specific devices Validate network changes and improvements over time

      Full URL Example:

      https://control.zequenze.com/api/v1/inventory_device_ipping/12345/

      Parameters:

      Parameter Type In Required Description
      id integer path Yes Unique identifier of the device for which to retrieve ping information

      ExamplecURL Request:Example:

      curl -X GET "https://control.zequenze.com/api/v1/inventory_device_ipping/123/12345/" \
  -H "Authorization: Bearer your-api-token-hereYOUR_API_TOKEN" \
  -H "Content-Type: application/json"

      Example Response:

      {
  "id": 123,12345,
  "device_id": 456,67890,
  "device_name": "web-server-01"Server-NYC-001",
  "ip_addresses": [
    {
      "address"ip_address": "192.168.1.100",
  "subnet_mask"ping_status": "255.255.255.0"active",
  "network"last_ping_time": "192.168.1.0/24"2024-01-15T14:32:15Z",
  "interface"response_time_ms": 12.5,
  "packet_loss_percentage": 0.0,
  "success_rate_24h": 99.8,
  "total_pings_24h": 1440,
  "failed_pings_24h": 3,
  "average_response_time_24h": 11.2,
  "min_response_time_24h": 8.1,
  "max_response_time_24h": 45.7,
  "ping_enabled": true,
  "ping_interval_seconds": 60,
  "timeout_seconds": 5,
  "last_successful_ping": "eth0"2024-01-15T14:32:15Z",
  "type"last_failed_ping": "static"2024-01-15T08:15:30Z",
  "primary"created_at": true"2024-01-10T09:00:00Z",
  "updated_at": "2024-01-15T14:32:15Z",
  "historical_data": [
    {
      "timestamp": "2024-01-15T14:30:00Z",
      "response_time_ms": 11.8,
      "status": "success"
    },
    {
      "address": "10.0.0.50",
      "subnet_mask": "255.255.0.0",
      "network": "10.0.0.0/16",
      "interface": "eth1",
      "type": "dhcp",
      "primary": false
    }
  ],
  "dns_servers": [
    "8.8.8.8",
    "8.8.4.4"
  ],
  "default_gateway": "192.168.1.1",
  "hostname": "web-server-01.example.com",
  "mac_addresses": [
    {
      "interface": "eth0",
      "address": "00:1B:44:11:3A:B7"
    },
    {
      "interface": "eth1",
      "address": "00:1B:44:11:3A:B8"
    }
  ],
  "last_updated"timestamp": "2024-01-15T10:30:15T14:29:00Z",
      "response_time_ms": 12.1,
      "status": "success"
    }
  ]
}

      Response Codes:

      Status Description
      200 SuccessfullySuccess retrieved- Returns ping information for the specified device IP configuration
      401 Unauthorized - Invalid or missing APIauthentication token
      404 Not Found - Device with specified ID does not foundexist or ping monitoring not configured
      500403 InternalForbidden server- errorInsufficient permissions to access device ping information

      Common Use Cases

      Use Case 1: Network Health Dashboard

      Retrieve ping metrics for multiple devices to build a real-time network health monitoring dashboard. Use this endpoint to gather connectivity status and response times for all critical infrastructure devices.

      Use Case 2: Troubleshooting Connectivity Issues

      When users report connectivity problems, fetch detailed ping history for the affected device to identify patterns, intermittent failures, or degraded performance that might indicate network issues.

      Use Case 3: Performance Baseline Establishment

      Collect historical ping data to establish performance baselines for network segments, helping to identify when response times deviate from normal patterns and require investigation.

      Use Case 4: Maintenance Window Planning

      Review ping success rates and failure patterns to identify optimal maintenance windows when devices experience the least connectivity issues or lowest usage periods.

      Best Practices

      • DevicePolling IdentificationFrequency: EnsureAvoid youexcessive haveAPI calls by implementing appropriate caching strategies. Consider the correctping deviceinterval IDconfigured beforefor makingdevices requestswhen determining how frequently to fetch updated data.

      • Error Handling: AlwaysImplement checkrobust error handling for 404 responsesresponses, whenas thedevices devicemay IDbe doesn'ttemporarily existunavailable or ping monitoring might be disabled for certain devices.

      • Rate Limiting: Implement appropriate delays between requests to avoid hitting API limits

      Data Freshness: Check the last_updated timestamp to determine if the IP configuration data is current

      Network PlanningInterpretation: Use the network24-hour statistics (success_rate_24h, average_response_time_24h) for trend analysis rather than relying solely on the most recent ping result, which may not be representative.

      Monitoring Thresholds: Establish appropriate thresholds for response times and subnetsuccess informationrates based on your network infrastructure and business requirements rather than using fixed values.

      Historical Data Usage: Leverage the historical_data array for IPtrend address managementanalysis and conflictpattern detectionrecognition, but be aware that the amount of historical data returned may be limited to prevent large response sizes.

      Back to top