What is best practices by config graylog rotation/retantion indexes?
If using open source, set retention to delete after reaching the set number of indices.
If using enterprise, set it to archive, then delete.
Related
I already know about the Azure App Configuration for storing application configurations such as connection strings for my Azure apps. However, I am now working on an Azure Functions app where I have to store a more complex configuration for my application.
The configuration consists of mappings where for each entry I have a key/id and multiple values associated with it. Ideally, I'd like to store this in a database table, but setting up a whole database just to store this configuration seems a bit excessive to me. There will be about 200 entries in this table and I don't expect this number to grow much in the future.
Is there a way to store this in a way how it can easily be edited later using an Azure App Configuration, or do I really need to create a new database just for this purpose? Is there maybe another alternative which I didn't consider so far?
Following suggestion is under the assumption that you are not going to edit that data frequently
One way to do is to create a hash table and store in configuration section in Function App. During run time, you can access the data. And for editing you just need to copy whole data from config section , edit it (using notepad++) and update it back to config section.
Though this is not an ideal way , it’s far better than having an dedicated DB just for this purpose ( plus the DB cost )
I am just looking for a way to track changes in a table of Cassandra. I don't want to use a trigger. If any changes made I will immediately update my data source.
Do you have any idea how to implement this feature using Java?
Also is it possible to create a plugin for Cassandra? I did not find any good resource to create a plugin for Cassandra.
Thanks.
I believe that what you are looking for is Change Data Capture (CDC)
You can read more on CDC in Apache Cassandra
In all servers we got some .env files, which sets configs for server (Node.JS) on start.
Now I want to edit this files from admin pane (another web-service, working with main server through API).
Is there any best practices or just good ideas how can I realize that?
First idea - create another web-server on instance, which will have only two API endpoints (read, write) and which will restart server after editing configs. This idea looking too heavy.
Second idea is to create bash script, which will send requests to admin servers to take actual configs and rewrite local .env file if find some changes, but here will be a lot unnecessary requests. (Request every minute, but configs will change 1 time per month).
What do you think? Any ideas?
You have a couple of options and it depends primarily on your deployment strategy..
If you have a distributed environment and/or your configuration changes often (i.e.: running multiple docker containers, rotating keys, etc.) I'd highly recommend using a K/V store and reading configuration(s) dynamically during application start. Check out HashiCorp Vault, etcd or even mongodb.
If your configuration contains sensitive data definitely use something like HashiCorp Vault. If you use a configuration tool like ansible, it has ansible-vault which will encrypt your secret(s) at rest and decrypt them during deployment.
I would highly advise against storing (even potentially) sensitive data such as api keys, tokens, etc. in version control. This is a pretty big attack vector and will lead you down a dark road.
Worst case scenario use environment variables. Almost all CI/CD tooling supports these and you can maintain separation of concerns.
Could someone advise, what is the best way to work with big application configurations which look like xml/json data? These data contain diff information(mostly static, but rarely it can be changed), but all of these data don't have security value.
For instance, it can be item options for an user control(like dropdown) in an application page or static data which is used as markup on the basis of which an web page creates a user control for page and so on.
I have several approaches for this:
Key vault. As I can undestand, the main idea of this storage is to work with security data like connection string, passwords and so on. How about using it to work with bigger and wider settings? The big plus for me, that this way contains built-in cache functionality, but it doesn't look like best practise way for me.
Storage account/Cosmos db - as far as I see, both of these ways are used similar and can be used for my target. The question is what is the most economic and productive way for me and will these ways better then the Key Vault way?
So, what is the most common solution for this target?
Thanks.
Hm, I think this answer realy depends on your requirements.
First of all, you can store / update and retrieve a complex configuration object in Azure App Services using the appsettings.json.
If you want to stick to files (xml / json) then you could use Azure Blob Storage.
If you just want to store larger configurations in a NoSQL store you could consider using Azure Table Storage (be aware that a single entry in the Table storage can only contain 252 properties and has a size limit of 1 MiB).
If you need to query your configuration by a configuration property (not by a key) or you think you will exceed the Azure Table Storage limits, then you could consider using CosmosDb
I'm quite new to CouchDB... let say that I have a multiple databases in my CouchDB, one per user, each of db have a one config document. I need to add a property to that document across all dbs. Is it possible to update that config document in all databases (not doing it one by one)? if yes what is the best way to achieve this?
If I'm reading your question correctly, you should be able to update the document in one database, and then use filtered replication to update the other databases (though you can't have modified the document in those other databases, otherwise you'll get a conflict).
Whether it makes sense for the specific use case, depends. If it's just a setting shared by all users, I'd probably create a shared settings database instead.
I do not think that is possible, and I don't think that is the intended use for CouchDB. Even if you have everything in a single database it's not possible to do it in a quick way (there is no equivalent to a SQL update/where statement).