I have recently upgraded my grafana image(helm chart) version 8.2.7 -> 9.3.1, After upgrade I noticed my existing alerts rules are missing
According to my analysis new version replaced the legacy alert configuration, So rollback the legacy alerting I tried following configuration in grafana.ini, but still my alert rules are missing
grafana.ini:
alerting:
enabled: true
unified_alerting
enabled: false
Reference
https://grafana.com/docs/grafana-cloud/alerting/migrating-alerts/roll-back/
https://github.com/grafana/helm-charts/issues/1464
Could anyone please advise me on this
Related
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.hibernate.search.elasticsearch.client.impl.DefaultElasticsearchClientFactory.createClient(DefaultElasticsearchClientFactory.java:92)
The following method did not exist:
org.elasticsearch.client.RestClientBuilder.setMaxRetryTimeoutMillis(I)Lorg/elasticsearch/client/RestClientBuilder;
The method's class, org.elasticsearch.client.RestClientBuilder, is available from the following locations:
jar:file:/home/temp/.gradle/caches/modules-2/files-2.1/org.elasticsearch.client/elasticsearch-rest-client/7.10.2/d0c857275bcec532079cdabb7913e2611c123e70/elasticsearch-rest-client-7.10.2.jar!/org/elasticsearch/client/RestClientBuilder.class
The class hierarchy was loaded from the following locations:
org.elasticsearch.client.RestClientBuilder:
file:/home/temp/.gradle/caches/modules-2/files-2.1/org.elasticsearch.client/elasticsearch-rest-client/7.10.2/d0c857275bcec532079cdabb7913e2611c123e70/elasticsearch-rest-client-7.10.2.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of org.elasticsearch.client.RestClientBuilder*
We need to use elasticsearch version 7.10.2 and currently we are using springboot version 2.3.9
any help?
is this correct mapping in application.yaml file for elastic search 7.10.2
hibernate:
format_sql: true
search.default:
elasticsearch:
dynamic_mapping: true
index_schema_management_strategy: update
required_index_status: yellow
https://stackoverflow.com/users/6692043/yrodiere
The version of the elasticsearch-rest-client dependency (Elasticsearch's low-level REST client) does not have to match the version of Elasticsearch server you actually use. elasticsearch-rest-client 7.16.3 will talk just fine to Elasticsearch server 7.10.2. And elasticsearch-rest-client 7.16.3 is licensed under ASL 2.0, if that's what you're worried about.
So, in short: do what the Hibernate Search documentation suggests, and upgrade to the latest version of elasticsearch-rest-client. See https://docs.jboss.org/hibernate/search/6.1/reference/en-US/html_single/#gettingstarted-framework-spring-boot-dependency-versions :
Spring Boot automatically sets the version of dependencies without your knowledge. While this is ordinarily a good thing, from time to time Spring Boot dependencies will be a little out of date. Thus, it is recommended to override Spring Boot’s defaults at least for some key dependencies.
With Maven, add this to your POM’s :
<properties>
<hibernate.version>5.6.5.Final</hibernate.version>
<elasticsearch.version>7.16.3</elasticsearch.version>
<!-- ... plus any other properties of yours ... -->
</properties>
If you use Elasticsearch's high-level REST client, now... you're in a pickle. That client is no longer open-source and can cause licensing issues. And its last open-source version (7.10.something) may not work with elasticsearch-rest-client 7.16.3. So if you really need to stick with version 7.10 or earlier of the high-level REST client, then you'll need to use older versions of elasticsearch-rest-client and Hibernate Search.
We have a java application (spring boot + hibernate search + elastic search).
Application is working fine on elastic search version 6.8
Recently, we have created a new cluster in aws with version 7.10.2 and updated elastic search endpoint in my java application.
After updating the elastic search endpoint I am getting error Can't update put mapping Types cannot be provided in put mapping requests, unless the include_type_name parameter is set to true and due to this unable to start the server.
I am not sure where to set include_type_name=true because all the indexes gets created automatically with #Indexed.
Can someone please let us know how can we fix this issue ?
Thanks #yrodiere for your response.
I tried to upgrade below dependencies version but unfortunately not able to fix it.
Previous Version:
compile 'org.hibernate:hibernate-search-orm:5.9.3.Final'
compile 'org.hibernate:hibernate-search-elasticsearch:5.9.3.Final'
compile 'org.hibernate:hibernate-search-elasticsearch-aws:5.9.3.Final'
Updated version :
compile 'org.hibernate:hibernate-search-orm:5.9.3.Final
compile 'org.hibernate.search:hibernate-search-backend-elasticsearch:6.1.1.Final'
compile 'org.hibernate.search:hibernate-search-backend-elasticsearch-aws:6.1.1.Final'
Note: If I downgrade this org.hibernate:hibernate-search-orm:5.9.3.Final then getting CE
am i missing something?
You're probably using Hibernate Search 5.x. In Hibernate Search 5.x, the Elasticsearch integration was experimental and only compatible with Elasticsearch up to version 5.6.
The fact that your application was working fine with Elasticsearch 6.8 was pure luck: Hibernate Search 5.x was never intended to work with Elasticsearch 6+.
To upgrade to a more recent version of Elasticsearch, you must upgrade to Hibernate Search 6.0 (or later). The API is different, but there is a very detailed migration guide, and at least you will get production-ready (non-experimental) Elasticsearch integration (plus tons of improvements).
Note that Hibernate Search 6.x also requires upgrading to Hibernate ORM 5.4; see this compatibility matrix.
Before the log4j shell issue happened last month I was using 'org.springframework.boot:spring-boot-starter-logging:1.5.22.RELEASE' which has internal dependencies on
ch.qos.logback:logback-classic:1.1.11 and ch.qos.logback:logback-core:1.1.11 jars respectively.
After that log4j shell issue occurred I had upgraded both the jars to version ch.qos.logback:logback-classic:1.2.3 and ch.qos.logback:logback-core:1.2.3 with gradle v3.5 which works fine. Now when I am trying to upgrade jars to logback-classic:1.2.10 and logback-core:1.2.10, this stops me while running the application stating below error:
org.gradle.tooling.BuildException: Could not execute build using Gradle distribution 'https://services.gradle.org/distributions/gradle-3.5-all.zip'.
Do I need to move to higher version of Grails or Gradle 3.5 have any issue with upgrade. Please any hint or guidance is most welcome.
From https://logback.qos.ch/news.html
We note that the vulnerability mentioned in CVE-2021-42550 requires
write access to logback's configuration file as a prerequisite. Please
understand that log4Shell and CVE-2021-42550 are of different severity
levels. In response to CVE-2021-42550 (aka LOGBACK-1591) we have
decided to make the following steps. 1) Hardened logback's JNDI lookup
mechanism to only honor requests in the java: namespace. All other
types of requests are ignored. Many thanks to Michael Osipov for
suggesting this change and providing the relvant PR. 2) SMTPAppender
was hardened. 3) Temporarily removed DB support for security reasons.
4) Removed Groovy configuration support. As logging is so
pervasive and configuration with Groovy is probably too powerful, this
feature is unlikely to be reinstated for security reasons. We note
that the aforementioned vulnerability requires write access to
logback's configuration file as a prerequisite. Please understand that
log4Shell/CVE-2021-44228 and CVE-2021-42550 are of different severity
levels. A successul RCE attack with CVE-2021-42550 requires all of the
following conditions to be met: write access to logback.xml use of
versions < 1.2.9 reloading of poisoned configuration data, which
implies application restart or scan="true" set prior to attack As an
additional extra precaution, in addition to upgrading to logback
version 1.2.9, we also recommend users to set their logback
configuration files as read-only
For now no support for grails so v1.2.9 onwards logback is not supported for now.
We are using serveral microservices with springboot (Vers. 1.4.3) and for monitoring them springboot-admin (Vers. 1.5.0).
Inside our microservices we generate several custom metrics (using the
'#com.codahale.metrics.annotation.Timed' annotation).
While all these custom metrics are displayed through the ordinary actuator-endpoint "/metrics" they are sorrowly not shown in the springboot admin GUI -"Metrics" tab.
Obviously only "counter." and "gauge." metrics are displayed in the latter.
Is there any possibility to configure / modify springboot admin, so that these custom metrics also are shown - either in the existing 'metrics' tab or in another new tab ?
Ok, meanwhile I found out, that the new springboot-admin version 1.5.2 will solve our problem:
As I could see at a project from a colleague, this springboot-admin version will display ALL metrics without any restrictions regarding the metrics-key.
[ At the moment we can't upgrade to this version since our springboot-version dependency prevents it but in the future we'll be able to do so.]
So the problem is more or less solved.
SonarQube Web Plugin created a lot of False Positives, because of the use of the JSP custom tags with "style" name.
Environment:
SonarQube 5.1
SonarQube Web Plugin 2.3
Jenkins 1.611
Sonar Runner 2.4
This is a bug in the rule. It marks all elements which local name is equal to style. Authors of the SonarQube Web Plugin have created an issue: SONARWEB-30. It will be fixed in 2.4 version.