aboutsummaryrefslogtreecommitdiffstats
path: root/service-monitor/src/test/java
Commit message (Collapse)AuthorAgeFilesLines
* Update copyrightJon Bratseth2023-10-0923-37/+37
|
* Remove usages in service-monitor as welljonmv2023-03-305-19/+15
|
* Use DomainName instead of the stricter HostName in duper-modeljonmv2023-03-305-23/+17
|
* Revert "Revert collect(Collectors.toList())"Henning Baldersheim2022-12-0410-14/+14
|
* Revert collect(Collectors.toList())Henning Baldersheim2022-12-0410-14/+14
|
* collect(Collectors.toList()) -> toList()Henning Baldersheim2022-12-0210-14/+14
|
* Revert "Merge pull request #22072 from ↵jonmv2022-04-098-19/+17
| | | | | | | vespa-engine/jonmv/unify-hostname-classes" This reverts commit 87e5b33c003d07ca585d73e0166857fe22b4c16f, reversing changes made to 80b96d32550ae0df59572a58cd62f507e8068c2c.
* Revert "Merge pull request #22068 from ↵jonmv2022-04-088-17/+19
| | | | | | | vespa-engine/jonmv/unify-hostname-classes" This reverts commit 8aa4c83df5ce7843c040afa41706fcc7c3afd030, reversing changes made to f95ad44fae879da9db19f73eabe62c53baeb0c36.
* Move ID part to HostName in config-provisioningjonmv2022-04-088-8/+8
|
* Revert "Merge pull request #22065 from ↵jonmv2022-04-088-26/+24
| | | | | | | vespa-engine/revert-22049-jonmv/unify-hostname-classes" This reverts commit 4ffc54339186574491a32b3166223c3fc50ba8fe, reversing changes made to db9e570a36decb24e6cb13f44bd0ff444ab762e3.
* Revert "Jonmv/unify hostname classes"Jon Marius Venstad2022-04-088-24/+26
|
* Use one HostName class (that is not for JSON)Jon Marius Venstad2022-04-088-26/+24
|
* Revert "Revert "Remove dev system""Håkon Hallingstad2022-01-171-2/+1
|
* Revert "Remove dev system"Harald Musum2022-01-171-1/+2
|
* Remove dev systemHåkon Hallingstad2022-01-141-2/+1
|
* Update Verizon Media copyright notices.gjoranv2021-10-071-1/+1
|
* Update 2018 copyright notices.gjoranv2021-10-0715-15/+15
|
* Update 2017 copyright notices.gjoranv2021-10-077-7/+7
|
* Remove use-unknown-service-status flagHåkon Hallingstad2021-09-293-3/+3
|
* Use unknown service status in testsHåkon Hallingstad2021-09-133-9/+9
|
* Add ServiceStatus.UNKNOWNHåkon Hallingstad2021-09-133-3/+3
|
* use a shared transport layer for health monitorJon Marius Venstad2021-05-032-4/+3
|
* Shut down transport threads of health monitorJon Marius Venstad2021-05-031-1/+3
|
* adminserver and topleveldispatch service names do not exist anymoreHarald Musum2020-08-031-8/+8
|
* Model cloud features explicitlyMartin Polden2020-05-061-3/+5
|
* Also remove hostnames from hostnamesById when removing hosts via application ↵Håkon Hallingstad2020-03-081-0/+36
| | | | | | | | activate I have seen a few "Host not found" messages in CD the last 2 days, and found this bug in how the duper model indices are maintained on application activation.
* Remove service model cacheHåkon Hallingstad2020-03-062-61/+3
|
* Listening to host changes to the service modelHåkon Hallingstad2020-03-043-13/+156
|
* Log and forward duper model completionHåkon Hallingstad2020-02-292-7/+3
|
* Add host indices to duper modelHåkon Hallingstad2020-02-281-3/+59
|
* Moved to more specific methods on ServiceMonitorHåkon Hallingstad2020-02-283-15/+14
|
* Disable service monitor cacheHåkon Hallingstad2020-02-251-1/+1
|
* Define completeness of SuperModel and DuperModelHåkon Hallingstad2020-02-232-1/+2
| | | | | | | | | | | | | In order for Orchestrator to remove application data from ZooKeeper, it must know which applications do NOT exist. Since the duper model starts with 0 applications, always, the only way of knowing what applications do not exist is for the bootstrap code to notify the super model/duper model when bootstrap is complete. There are 2 sources of applications that must signal completeness: - The super model, once all applications have been redeployed in ConfigServerBootstrap. - The infrastructure application, in the InfrastructureProvisioner the first time it runs.
* Allow dev hosts with only ipv4Morten Tokle2019-11-151-1/+2
|
* Use mockito-core 3.1.0Håkon Hallingstad2019-10-188-8/+8
|
* Remove ZoneApplicationValerij Fredriksen2019-06-072-94/+5
|
* Simplify ApplicationInstanceGeneratorValerij Fredriksen2019-06-071-76/+1
|
* Simplify health monitoringValerij Fredriksen2019-06-072-80/+0
|
* Only allow activate/remove legal infra applications in duper modelValerij Fredriksen2019-06-011-29/+26
|
* Remove MONITOR_TENANT_HOST_HEALTH flagValerij Fredriksen2019-06-013-53/+14
|
* Remove nodeAdminInContainer from configserver.defValerij Fredriksen2019-06-011-3/+1
|
* Tenant hosts only have node-admin serviceHåkon Hallingstad2019-05-231-0/+70
| | | | | | | | | | | | Tenant hosts are allocated to the zone (routing) app in the node-admin cluster. These hosts also have various other services like logd, config-sentinel, etc that do not run. The metricsproxy container is a new service that will be added to all hosts, and that will be Slobrok monitored. Except, it will not run on tenant hosts as above. To avoid having metrics cluster spanning the whole of the zone app, and have them DOWN on all tenant hosts, we'll filter those service away from the model when generating the ApplicationInstance of the service model.
* Make port tag comparison case insensitiveHåkon Hallingstad2019-02-031-0/+15
|
* Health rest APIHåkon Hallingstad2019-01-314-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Makes a new REST API /orchestrator/v1/health/<ApplicationId> that shows the list of services that are monitored for health. This information is currently a bit difficult to infer from /orchestrator/v1/instances/<ApplicationInstanceReference> since it is the combined view of health and Slobrok. There are already APIs for Slobrok. Example content: $ curl -s localhost:19071/orchestrator/v1/health/hosted-vespa:zone-config-serve\ rs:default|jq . { "services": [ { "clusterId": "zone-config-servers", "serviceType": "configserver", "configId": "zone-config-servers/cfg6", "status": { "serviceStatus": "UP", "lastChecked": 1548939111.708718, "since": 1548939051.686223, "endpoint": "http://cfg4.prod.cd-us-central-1.vespahosted.ne1.yahoo.com:19071/state/v1/health" } }, ... ] } This view is slightly different from the application model view, just because that's exactly how the health monitoring is structured (individual monitors against endpoints). The "endpoint" information will also be added to /instances if the status comes from health and not Slobrok.
* Metadata about /state/v1/health statusHåkon Hallingstad2019-01-2511-55/+57
| | | | | | | | | | | | | The service monitor uses /state/v1/health to monitor config servers and the host admins (but not yet tenant host admins). This commit adds some metadata about the status of a service: - The time the status was last checked - The time the status changed to the current This can be used to e.g. make more intelligent decisions in the Orchestrator, e.g. only allowing a service to suspend if it has been DOWN longer than X seconds (to avoid spurious DOWN to break redundancy and uptime guarantees).
* Support monitoring health of tenant hostsHåkon Hallingstad2019-01-164-15/+206
|
* Remove healthmonitor-monitorinfra, dupermodel-contains-infra, ↵Håkon Hallingstad2019-01-145-106/+27
| | | | dupermodel-use-configserverconfig, proxyhost-uses-real-orchestrator, and confighost-uses-real-orchestrator flags
* Typed flag classesHåkon Hallingstad2019-01-031-3/+2
| | | | | | | | | | This reintroduces the non-generic flag classes: - a value() returns the primitive type for flags wrapping a primitive type - easier to use in testing - Serializer is moved to internals of typed class Defines the flag backed by boolean BooleanFlag instead of FeatureFlag since not all boolean flags are necessarily guarding a feature.
* Configserver flags REST APIHåkon Hallingstad2018-12-301-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds a new ZooKeeper backed flag source. It is defined in a new module configserver-flags to allow as many as possible config server modules to depend on it by minimizing dependencies. The content of the ZK backed flag source can be viewed and modified through REST API on the config server/controller. The data stored per flag looks like { "rules": [ { "conditions": [ { "type": "whitelist", "dimension": "hostname", "values": ["host1"] } ], "value": true } ] } typical for enabling a feature flag on host1. 2 types of conditions are so far supported: whitelist and blacklist. All the conditions must match in order for the value to apply. If the value is null (or absent), the default value will be used. At the time the flag's value is retrieved, it is resolved against the conditions with the current zone, hostname, and/or application. The same data structure is used for FileFlagSource for files in /etc/vespa/flags with the ".2" extension. The FlagSource component injected in the config server is changed to: 1. Return the flag value if specified in /etc/vespa/flags, or otherwise 2. return flag value from ZooKeeper (same as REST API) The current flags (module) is also changed: - All flags must be defined in com.yahoo.vespa.flags.Flags. This allows the ZK backed flag source additional sanity checking when modifying flags. - If it makes sense to have different flag value depending on e.g. the application, then at some point before the value is retrieved, one has to bind the flag to that application (using with() to set up the fetch vector). Future changes would be to 0. make a merged FlagSource in host admin, 1. add support for viewing and modifying feature flags in dashboard, 2. in hv tool.
* Use thread pool for health monitoring in service-monitorHåkon Hallingstad2018-12-1710-133/+549
| | | | | This is necessary to avoid using too many threads when monitoring the host-admin on the tenant Docker hosts.