{"id":"503e063a-693e-41a7-bfa9-1addd9cebe38","arxiv_id":"2411.17753","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":1.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A review chapter that organizes the state of the art of observability in fog computing, including a data lifecycle, topologies, tools, and a testbed example, without presenting new experimental results.","lead":"This preprint is a survey chapter about observability in fog computing, the practice of collecting metrics, logs, and traces from distributed edge devices to speed up failure diagnosis. It maps challenges, architectures, tools, and a testbed example, which is useful for engineers planning monitoring for IoT and edge systems.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Section 1.6 claims 'benefits' were collected at low overhead, but the testbed reports only overhead and no benefit metric; 25% CPU/5 GiB on Fog nodes also strains the 'low' label.","rationale":"I read the paper as a survey chapter whose experimental core is §1.6. The reader's conditional verdict is reasonable: the survey, the ODLC framing, and the tool taxonomy are useful reference material, but the paper's only quantified evidence for its feasibility claim is a small, tuned testbed. My additional load-bearing concern is that the concluding sentence of §1.6 asserts both 'benefits' and 'low overhead', while the text reports only resource-consumption numbers and no benefit outcome. The Fog-node figures (25% CPU, 5 GiB memory) are labeled low without stating node capacities or baseline load, which matters because the paper itself emphasizes resource-restricted Fog devices. The manually limited metric set and one-week retention further scope the result, so the numbers describe a configured deployment rather than a general bound. I do not see an internal inconsistency that warrants rejection; the right remedy is to rewrite §1.6's final claim, add the missing context from [29], and fix the copyediting artifacts (the 'The provided LaTeX text has been paraphrased as requested' sentence in §1.5.2 and the duplicate Fluentd row in Table 1.2). My agreement with the reader is partial because the reader emphasizes external generalization, while I emphasize the missing benefit measurement and the undefined 'low' threshold for the resource-restricted Fog layer; both point to the same conditional acceptance.","tokens_in":98,"tokens_out":7116,"duration_ms":122198,"concrete_test":"Open the companion paper [29] (the source of the testbed described in §1.6) and list every measured dependent variable in its Fog-observability experiment. If the list contains no benefit-related quantity (time-to-detection, MTTR, availability, number of incidents detected), then the 'collect the benefits' portion of the §1.6 claim is unsupported. Also record whether the 5 GiB Fog-node memory figure is accompanied by the total RAM of the Fog nodes; if it is not, the 'low overhead' portion of the claim is unquantified and should be qualified or removed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central evidentiary claim is the final sentence of §1.6: the experiments showed it is possible to collect the benefits of higher observability in Fog with low resource overhead. This is the paper's only experimental support for the benefit/cost tradeoff, and it is weaker than the sentence implies. First, the reported testbed measured resource consumption (IoT CPU/memory, Fog CPU/memory, weekly data volume) but no benefit metric: no time-to-detection, mean-time-to-repair, availability, or troubleshooting outcome is reported. The benefits named in the claim are imported from the general observability discussion, not from the experiment. Second, the 'low overhead' label is not established for the Fog layer: 25% CPU and 5 GiB memory are presented without the capacities of the two Fog nodes, the baseline application load, or run-to-run variance. Since §1.2.1 defines Fog nodes as including smartphones, routers, and notebooks, 5 GiB is not self-evidently low and may be a large fraction of a resource-restricted node's memory. Third, the measurement is explicitly tuned: the metric set was manually limited to application-relevant metrics and retention was capped at one week, so the numbers apply to that configuration and no scaling behavior is given for larger metric sets, larger fleets, or unreliable networks. These are limitations, not errors, but they mean the central claim is overbroad as written.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper is a survey/tutorial chapter on observability in Fog Computing. It reviews the three pillars of observability (metrics, logs, traces), introduces the Observability Data Life Cycle (ODLC), discusses challenges and approaches, presents a three-component architecture and three topologies, surveys open-source tools for metrics, logs, traces, storage, and visualization, and describes a solution example based on the Mobile IoT-RoadBot Smart City application. The solution example reports a testbed with 4 IoT devices, 2 Fog nodes, and 1 cloud VM running NodeExporter, Filebeat, OpenTelemetry, Prometheus, Elasticsearch, Jaeger, and Grafana, and it reports resource overhead figures (IoT CPU <12%, IoT memory <150 MiB, Fog node CPU up to 25%, Fog node memory 5 GiB, 2 GB weekly observability data). The chapter concludes that the experiments showed it is possible to obtain the benefits of higher observability in Fog at low resource overhead.","tokens_in":20468,"tokens_out":4082,"duration_ms":35054,"significance":"If taken as a survey, the chapter provides a useful consolidation of concepts, a clear enumeration of challenges, and a convenient tool table (Table 1.2) that practitioners could use to assemble an observability stack. The architecture and topology discussion are reasonable and well referenced. The solution example is a concrete demonstration that an open-source observability stack can be deployed in a Fog-like environment, and the reported overhead numbers are a starting point for further evaluation. However, the paper's only experimental evidence for the benefit/cost tradeoff is the solution example, and it measures only resource consumption, not any benefit metric. The small, manually tuned testbed means the empirical claim 'low overhead' is not yet established at scale. These limitations do not invalidate the survey content, but they require the empirical claim to be substantially qualified. There are no machine-checked proofs or public datasets; the main strengths are the descriptive synthesis and the practical tool-oriented overview.","major_comments":[{"comment":"The claim that 'the experiments showed that it is possible to collect the benefits of achieving a higher level of observability for a system in a Fog computing environment with a low overhead in terms of resource usage' is not supported by the reported data. The experiment measures only resource overhead (IoT CPU/memory, Fog CPU/memory, and weekly data volume) and no benefit metric such as time-to-detection, mean-time-to-repair, availability, or troubleshooting outcome. The 'benefits' are imported from the general observability discussion rather than from the experiment itself. Please reword the claim to state what was actually demonstrated, for example, the feasibility of deploying a three-pillar observability stack with the measured resource overhead, or add a quantitative benefit metric to the evaluation.","section":"§1.6 (Solution Example, final sentence)"},{"comment":"The label 'low overhead' is not established for the Fog node. The reported 25% CPU and 5 GiB memory are presented without the total capacity of the two Fog nodes, the baseline application load, or run-to-run variance. Since §1.2.1 defines Fog nodes as potentially smartphones, routers, or notebooks, 5 GiB is not self-evidently low and could be a large fraction of the memory of a resource-restricted node. Please report the node capacities, baseline utilization, and experimental variance, or qualify the 'low' characterization to the specific node types used in the testbed.","section":"§1.6 (overhead figures)"},{"comment":"The overhead figures are obtained under explicitly tuned conditions: the metric set was manually limited to 'only the ones of interest to the application', the retention window on the Fog node was capped at one week, and the testbed includes only 4 IoT devices, 2 Fog nodes, and 1 cloud VM. No scaling behavior is given for larger metric sets, larger device fleets, or unreliable network conditions. As written, the claim refers to 'a Fog computing environment' generally, which overgeneralizes from this single configuration. Please add a limitations paragraph that explicitly scopes the overhead results to the described testbed and avoids implying universal low overhead.","section":"§1.6 (measurement configuration and generalizability)"}],"minor_comments":[{"comment":"The sentence 'The provided LaTeX text has been paraphrased as requested.' appears in the manuscript and is clearly a pipeline artifact; it should be removed.","section":"§1.5.2 (Filebeat)"},{"comment":"The tool name 'Logtash' is a misspelling of 'Logstash'. In Table 1.2, the Fluentd row is duplicated; the second row labeled 'Fluentd' describes 'Part of ELK stack', which actually refers to Logstash.","section":"§1.5.2 and Table 1.2"},{"comment":"In the list of interchangeable data format tools, 'collected' should be 'collectd' (the system statistics collection daemon).","section":"§1.7 (Future Directions)"},{"comment":"There is a missing space in 'a suitableFog observability solution'; it should read 'a suitable Fog observability solution'.","section":"§1.2.3 (Transmission step)"},{"comment":"The notation for the X operator, especially the expansion '(IDiXIDjXIDk)' and the 'IDixIDj' expressions, is not typeset with standard mathematical formatting and is difficult to parse. Please rewrite using clear set operators or relational symbols.","section":"Equation 1.3 and surrounding text"},{"comment":"The phrase 'metrics, log, and traces' should be 'metrics, logs, and traces' for consistency with the rest of the chapter.","section":"Abstract"}],"recommendation":"major_revision","confidential_remarks":"The manuscript reads as a book chapter rather than a standalone research article. Its central empirical claim relies heavily on the authors' own prior work, particularly [12] and [29]; the 'gap' statement that no existing proposal manages metrics, logs, and traces simultaneously is supported only by the authors' own earlier review. The experimental section is essentially a summary of [29] rather than new evidence. If the venue expects original empirical contributions, the fit may be questionable; as a survey/tutorial chapter, the descriptive content is acceptable after the empirical claims are scoped and the minor artifacts are removed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a survey chapter, not a new research result. The genuinely useful parts are the structured tour of observability concepts, the architecture/topology discussion, and the tool table. The weak part is Section 1.6, where the text claims the experiments showed it is possible to 'collect the benefits' of observability at low overhead; the reported testbed measured only resource consumption, no benefit metric, and the fog-node numbers (25% CPU, 5 GiB) are not self-evidently 'low' without node capacities or variance.\n\nWhat it does well: it pulls together the three pillars, the ODLC (from the authors' prior work), the centralized/decentralized/distributed topologies, and a comprehensive tool table (Table 1.2). The challenges section is standard but competently summarized. For someone new to fog observability, this is a readable entry point.\n\nSoft spots, in proportion:\n\n1. The empirical claim is overbroad. The testbed has 4 IoT devices, 2 fog nodes, 1 cloud VM. Metrics were manually limited to 'only the ones of interest', and retention on the fog node was capped at one week. No confidence intervals, no baseline application load, no public artifacts. The numbers may be fine for that configuration, but they don't justify a general 'low overhead' statement, especially at the fog layer.\n\n2. No benefit metric. The experiment measured CPU/memory and data volume only. The 'benefits' of higher observability are imported from the general discussion; they were not measured. The final sentence of Section 1.6 should be reworded or removed.\n\n3. Novelty is explicitly low. The observability index and ODLC come from [12] and [29]. That is fine for a survey, but the framing should be honest about being a survey, not a new contribution.\n\n4. Minor editing artifact: Section 1.5.2 on Filebeat contains the sentence 'The provided LaTeX text has been paraphrased as requested.' That must be removed. Also 'Logtash' vs 'Logstash' typo.\n\nThe citation pattern is acceptable, though self-citation is heavy; the authors do cite the prior works when they reuse them.\n\nWho it's for: practitioners and graduate students wanting a structured overview and a tool list. It doesn't resolve open problems. Still, as a survey it has enough organization and reference value to deserve a serious referee—if the authors fix the artifact, qualify the overhead claim, and either provide data or clearly label the testbed as illustrative. I'd engage with it as a survey, conditionally, not as a new research result.","headline":"A competent survey of fog observability that overstates its small testbed's support for 'low overhead'; useful as a reference, not as a new research result.","tokens_in":21059,"tokens_out":2642,"would_cite":false,"duration_ms":24310,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This chapter claims that fog computing can support full observability (metrics, logs, and traces) with low resource overhead, supported by a testbed where device CPU stayed below 12%.","keywords":["Fog Computing","Observability","IoT","Metrics","Logs","Traces","Monitoring","OpenTelemetry"],"falsifier":"Run the same open-source observability stack on a larger, more heterogeneous fleet (hundreds of IoT devices) over low-bandwidth or intermittent links with the full default metric set; if IoT-device CPU or memory rises sharply, fog-node CPU exceeds 25%, or application latency degrades measurably compared with a no-telemetry baseline, the low-overhead claim fails in that regime. Alternatively, a side-by-side trial showing no reduction in time-to-restore for a metrics–logs–traces deployment versus metrics-only monitoring would weaken the practical benefit claim.","tokens_in":20014,"feed_emoji":"📡","tokens_out":6255,"duration_ms":53327,"temperature":0.7,"pith_summary":"This chapter argues that observability in fog computing—collecting metrics, logs, and traces so operators can see a system's internal state—is practical without overwhelming resource-limited devices. It proposes a six-step data lifecycle that keeps most telemetry on fog nodes and archives only older data to the cloud, plus an agent–transformer–server architecture that maps onto existing open-source tools. The supporting experiment on a four-device, two-fog-node testbed reports device-side overhead below 12% CPU and 150 MiB memory, with weekly telemetry volume under 1% of the application's normal data flow. The conclusion is that fog environments can carry full observability at a modest resource cost, while heterogeneity, scattered data sources, resource consumption, and security remain open challenges.","feed_headline":"Fog observability adds under 12% device CPU with open-source tools","feed_subtitle":"A four-device testbed shows metrics, logs, and traces can run on fog nodes for about 2 GB of telemetry a week.","key_machinery":"The load-bearing mechanism is the Observability Data Life Cycle (ODLC), six stages—collection, IoT storage, transmission to fog, fog storage, analysis and visualization, cloud storage and analysis—that partition telemetry work so IoT devices only collect and forward while fog and cloud nodes absorb storage and analysis. The observability index and its synergy term formalize why all three domains are worth collecting together. The agent–transformer–server component model and the three topologies (centralized, decentralized, distributed) give the deployment structure that the testbed instantiates with open-source containers.","core_discovery":"The central claim is that a fog environment can run all three pillars of observability—metrics, logs, and traces—alongside its applications, as long as the telemetry lifecycle keeps the load off constrained IoT devices. The paper defines an observability index that counts the available domains and adds a synergy term $\\mathrm{Metrics}\\times\\mathrm{Logs}\\times\\mathrm{Traces}$, which is 1 only when time-correlated data exist in more than one domain; this makes cross-domain analysis part of what observability means, not an extra. It then splits the problem into collection, IoT storage, transmission, fog storage, analysis and visualization, and cloud archiving, and into agent, transformer, and server components. The experimental basis is an observability stack (NodeExporter, Filebeat, OpenTelemetry, Prometheus, Elasticsearch, Jaeger, Grafana) deployed on a smart-city roadside-monitoring application, where IoT-device CPU stayed below 12%, memory below 150 MiB, fog-node server overhead reached 25% CPU and 5 GiB memory, and a week of observability data totalled about 2 GB. The authors conclude that these numbers make higher observability achievable in fog computing with low resource overhead.","pith_inferences":["The reported overhead numbers come from a testbed with only four IoT devices and two fog nodes; a production-scale fleet with full default metric sets and lossy networks could push device CPU or fog-node memory well above these figures.","The paper discusses adaptive collection and eBPF as future directions; a natural testable extension is an adaptive controller that reduces collection frequency or drops a domain when device or network load rises, which the testbed architecture could support but does not evaluate.","If the observability index's synergy term is meant to predict operational value, the next experiment would be to compare mean time to restore with and without cross-domain correlation, holding tooling constant."],"forward_implications":["Operators can deploy a complete metrics–logs–traces stack on fog nodes using open-source tools, with IoT-device overhead under 12% CPU and under 150 MiB memory.","Fog-node server components, not the device agents, are the resource bottleneck: Prometheus, Elasticsearch, Jaeger, and Grafana consumed up to 25% CPU and 5 GiB memory on the fog node.","Restricting metrics to application-relevant ones and keeping data on the fog node for a week keeps weekly telemetry to about 2 GB, under 1% of the application's 5G data volume.","Cross-domain time-correlation (the synergy term) yields more observability than any single instrumented domain, which justifies running all three pillars despite the added load.","Automatic cloud archival of aged observability data prevents fog storage and IoT device storage from being saturated, keeping the lifecycle sustainable."],"supporting_citations":[{"why":"Provides the testbed experiment and the measured CPU, memory, and data-volume overheads that ground the central claim.","marker":"[29]"},{"why":"Supplies the data characteristics of metrics, logs, and traces and the argument that they need different storage and query engines, motivating the architecture.","marker":"[6]"},{"why":"The authors' earlier systematic review finding that no existing fog monitoring proposal handles all three domains simultaneously, framing the gap this chapter addresses.","marker":"[12]"},{"why":"Defines the fog computing characteristics (low latency, geographic distribution, heterogeneity, interoperability, real-time interaction, scalability) that make observability hard.","marker":"[2]"},{"why":"Supports the assumptions that observability data are most valuable when queried soon after arrival and that logs and traces need inverted-index storage, shaping the lifecycle's data-retention rules.","marker":"[25]"},{"why":"Describes the Mobile IoT-RoadBot smart-city application used as the testbed workload for the observability deployment.","marker":"[65]"},{"why":"Source for the 'three pillars' of observability (metrics, logs, traces) that the chapter uses as its organizing frame.","marker":"[24]"}],"fun_headline_variants":["Fog observability adds less than 12% CPU to IoT devices","Open-source stack brings metrics, logs, traces to fog nodes","Fog telemetry: 2 GB per week, <12% IoT device CPU","Observability in fog: low overhead, full three pillars","Under 12% CPU: observability for constrained fog devices"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The measured low overhead from a four-device, two-fog-node testbed generalizes to real fog environments, even though the metric set was manually limited, fog-node retention was capped at one week, and the network was not stressed.","fun_headline_variants_meta":{"raw":{"variants":["Fog observability adds less than 12% CPU to IoT devices","Open-source stack brings metrics, logs, traces to fog nodes","Fog telemetry: 2 GB per week, <12% IoT device CPU","Observability in fog: low overhead, full three pillars","Under 12% CPU: observability for constrained fog devices"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000299,"raw_usage":{"total_tokens":1763,"prompt_tokens":1011,"completion_tokens":752,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":627,"completion_tokens_details":{"reasoning_tokens":660}},"tokens_in":627,"tokens_out":752,"duration_ms":6817,"temperature":1.0,"reasoning_tokens":660,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T12:51:48.112298+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same open-source observability stack on a larger, more heterogeneous fleet (hundreds of IoT devices) over low-bandwidth or intermittent links with the full default metric set; if IoT-device CPU or memory rises sharply, fog-node CPU exceeds 25%, or application latency degrades measurably compared with a no-telemetry baseline, the low-overhead claim fails in that regime. Alternatively, a side-by-side trial showing no reduction in time-to-restore for a metrics–logs–traces deployment versus metrics-only monitoring would weaken the practical benefit claim.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the testbed experiment and the measured CPU, memory, and data-volume overheads that ground the central claim."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the data characteristics of metrics, logs, and traces and the argument that they need different storage and query engines, motivating the architecture."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The authors' earlier systematic review finding that no existing fog monitoring proposal handles all three domains simultaneously, framing the gap this chapter addresses."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the fog computing characteristics (low latency, geographic distribution, heterogeneity, interoperability, real-time interaction, scalability) that make observability hard."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supports the assumptions that observability data are most valuable when queried soon after arrival and that logs and traces need inverted-index storage, shaping the lifecycle's data-retention rules."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Describes the Mobile IoT-RoadBot smart-city application used as the testbed workload for the observability deployment."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Source for the 'three pillars' of observability (metrics, logs, traces) that the chapter uses as its organizing frame."}],"review_version":1}