Bug: Service monitor state inconsistent — NoData shows with timeout error / Good shows with Error: prefix

Description

Service monitoring notification logic produces two observable inconsistencies:

1. [NoData] + error message like dial tcp ...: i/o timeout

File: service/singleton/servicesentinel.go → processReport + GetStatusCode

When a service monitor's result buffer is cleared (30 items written to DB), the next agent report arrives. The code:

ss.serviceResponseDataStore[mh.GetId()] = serviceResponseData{}  // clear
for _, cs := range serviceCurrentStatusData.result { ... }  // rebuild from empty buffer

The rebuild loop iterates over an empty result buffer, producing Up=0, Down=0, which makes GetStatusCode(0) return StatusNoData. But mh.Data (the actual error from the current report) is carried through verbatim, producing notifications like:

[NoData] service-name Reporter: agent-1, Error: dial tcp x.x.x.x:46714: i/o timeout

This is contradictory: the agent did report (with a timeout), but the system says "NoData" and includes the timeout error text. The correct state should be StatusDown since the agent reported a failed probe.

Suggested fix: When the buffer is empty but a current report exists, use the current report's Successful field to determine state instead of defaulting to NoData.

2. [Good] notification includes Error: prefix with empty content

File: service/singleton/servicesentinel.go → notifyCheck

The notification message template is:

notificationMsg := Localizer.Tf("[%s] %s Reporter: %s, Error: %s",
    StatusCodeToString(stateCode), ss.Name, reporterServer.Name, mh.Data)

When state is Good (successful probe), mh.Data is typically empty for ICMP/TCP probes, producing:

[Good] service-name Reporter: agent-1, Error:

The Error: prefix is meaningless on a success notification.

Suggested fix: Only include Error: in the message when the state is not Good, or use a different field name (e.g., Info:) for successful probes.

Environment

• Version: latest (cloned from main branch)
• Service monitor type: TCP Ping
• Duration: 300s