web-dev-qa-db-fra.com

Impossible d'exporter vers le service de surveillance car: Erreur Gax RPC a échoué, causé par 3

J'ai une application Java Application dans App Engine, et récemment, j'ai commencé à recevoir l'erreur suivante:

Unable to export to Monitering service because: GaxError RPC failed, caused by 3:One or more TimeSeries could not be written: Metrics cannot be written to gae_app. See https://cloud.google.com/monitoring/custom-metrics/creating-metrics#which-resource for a list of writable resource types.: timeSeries[0]

et cela se produit à chaque fois après le journal de vérification de l'état:

Health checks: instance=instanceName start=2020-01-14T14:28:07+00:00 end=2020-01-14T14:28:53+00:00 total=18 unhealthy=0 healthy=18

et après un certain temps, mes instances seraient redémarrées et la même chose recommencerait.

app.yaml:

 #https://cloud.google.com/appengine/docs/flexible/Java/reference/app-yaml

#General settings
runtime: Java
api_version: '1.0'
env: flex
runtime_config:
  jdk: openjdk8
#service: service_name #Required if creating a service. Optional for the default service.

#https://cloud.google.com/compute/docs/machine-types
#Resource settings
resources:
  cpu: 2
  memory_gb: 6 #memory_gb = cpu * [0.9 - 6.5] - 0.4
#  disk_size_gb: 10 #default

##Liveness checks - Liveness checks confirm that the VM and the Docker container are running. Instances that are deemed unhealthy are restarted.
liveness_check:
  path: "/liveness_check"
  timeout_sec: 20         #1-300   Timeout interval for each request, in seconds.
  check_interval_sec: 30 #1-300   1-300Time interval between checks, in seconds.
  failure_threshold: 6   #1-10    An instance is unhealthy after failing this number of consecutive checks.
  success_threshold: 2   #1-10    An unhealthy instance becomes healthy again after successfully responding to this number of consecutive checks.
  initial_delay_sec: 300 #0-3600  The delay, in seconds, after the instance starts during which health check responses are ignored. This setting can allow an instance more time at deployment to get up and running.

##Readiness checks - Readiness checks confirm that an instance can accept incoming requests. Instances that don't pass the readiness check are not added to the pool of available instances.
readiness_check:
  path: "/readiness_check"
  timeout_sec: 10             #1-300      Timeout interval for each request, in seconds.
  check_interval_sec: 15      #1-300      Time interval between checks, in seconds.
  failure_threshold: 4       #1-10    An instance is unhealthy after failing this number of consecutive checks.
  success_threshold: 2       #1-10    An unhealthy instance becomes healthy after successfully responding to this number of consecutive checks.
  app_start_timeout_sec: 300 #1-3600  The maximum time, in seconds, an instance has to become ready after the VM and other infrastructure are provisioned. After this period, the deployment fails and is rolled back. You might want to increase this setting if your application requires significant initialization tasks, such as downloading a large file, before it is ready to serve.

#Service scaling settings
automatic_scaling:
  min_num_instances: 2
  max_num_instances: 3
  cpu_utilization:
    target_utilization: 0.7
google-app-enginegoogle-cloud-platformgoogle-cloud-stackdriver
7
Shb

L'erreur est causée par une mise à niveau du side-car de journalisation de stackdriver vers version 1.6.25 , qui commence à pousser les métriques FluentD vers Stackdriver Monitoring via OpenCensus. Cependant, l'intégration avec App Engine Flex ne fonctionne pas encore.

Ces erreurs ne doivent être que des journaux. Il n'est pas relatif aux journaux de vérification de l'état. Cela ne devrait pas avoir d'impact sur VM restart. Si vos instances VM) redémarrent fréquemment, cela peut être dû à une autre raison. Dans l'interface utilisateur de Stackdriver Logging, vous pouvez effectuer une recherche. Free disk space sous vm.syslog stream et unhealthy sidecars sous vm.events flux. Si certains journaux s'affichent, le redémarrage de vos instances peut être dû à une faible taille de disque libre ou à des conteneurs side-car défectueux.

2
Yanwei Guo