telegram-bot-manager icon indicating copy to clipboard operation
telegram-bot-manager copied to clipboard

Feature request

Open jacklul opened this issue 7 years ago • 10 comments

  • [x] Add getWebhookInfo result to GET/CLI parameters action #29
  • [x] Categorize config array https://github.com/php-telegram-bot/telegram-bot-manager/issues/13#issuecomment-294529708
  • [x] Botan options
  • [ ] Log rotator
  • [ ] Build-in log/exception reporter to admins ?

jacklul avatar Apr 17 '17 20:04 jacklul

Please add some extra explanations for each bit 👍

Add getWebhookInfo result to GET/CLI parameters action

So every request does an extra request for the webhook info? If so, I think we wait for the options table to be implemented, to offer an easy way to cache the value at least.

Categorize config array #13 (comment)

Will be done 🎉

Botan options

This one is easy to implement, just need to know what options you'd like to have in here, as I'm not very familiar with Botan.

Log rotator

As in, define a maximum size of log file before it gets rotated? Or line count? Something simple it must be 😉

Build-in log/exception reporter to admins ?

So that admins get a message every time an exception happens?

noplanman avatar Apr 18 '17 09:04 noplanman

Add getWebhookInfo result to GET/CLI parameters action

What I mean is manager.php a=info that shows the webhook info.

Botan options

Simply array for options that will be passed to enableBotan()

Log rotator

Well, let the user choose in this case:

Build-in log/exception reporter to admins ?

This I meant as a addition to rotator, maybe the user could specify if he wants the log to be sent when it reaches xx size, xx lines or becomes xx seconds old or send log that got rotated and archived.

jacklul avatar Apr 18 '17 09:04 jacklul

a=info is really pointing towards making a better CLI tool for the bots. Something like WP-CLI (which you might now, and @lichtscheu most probably). It's a CLI for WordPress, which makes administration a breeze, and being able to execute commands without having to load the entire CMS.

As for the config array, I've put some thought into it and have come up with this merged version of your ideas with mine. I've moved the commands paths into the commands section, not 100% sure about that one yet, as it would fit perfectly into the paths one too 😕 Also, for cron I've made groups, so that different commands could be grouped and executed together. Give me you feedback on this!

$config = [
    // Basics
    'api_key'      => getenv('BOT_API_KEY'),
    'bot_username' => getenv('BOT_USERNAME'),
    'secret'       => getenv('BOT_SECRET'),

    // Paths
    'paths'        => [
        'download' => ROOT_PATH . '/download/',
        'upload'   => ROOT_PATH . '/upload/',
    ],

    // Database
    'mysql'        => [
        'host'     => getenv('DB_HOST'),
        'user'     => getenv('DB_USER'),
        'password' => getenv('DB_PASS'),
        'database' => getenv('DB_NAME'),
        //'table_prefix' => getenv('DB_TABLE_PREFIX'),
        //'encoding'     => getenv('DB_ENCODING'),
    ],

    // Webhook
    'webhook'      => [
        'url'             => getenv('BOT_WEBHOOK'),
        //'certificate'     => 'certificate.crt',
        'max_connections' => 100,
        'allowed_updates' => ['message', 'edited_message', 'inline_query', 'chosen_inline_result', 'callback_query'],
    ],

    // Logging
    'logging'      => [
        'error' => ROOT_PATH . '/logs/Error.log',
        //'debug'  => ROOT_PATH . '/logs/Debug.log',
        //'update' => ROOT_PATH . '/logs/Update.log',
    ],

    // Settings
    'admins'       => [(integer) getenv('BOT_ADMIN')],

    // Commands
    'commands'     => [
        'paths'   => [
            ROOT_PATH . '/Commands/',
        ],
        'configs' => [
            'randomcommand' => [
                'api_key' => getenv('RANDOM_COMMAND_API_KEY'),
            ],
        ],
    ],

    // Extra features
    'botan'        => [
        'token'   => getenv('BOTAN_TOKEN'),
        'options' => [
            'timeout' => 1,
        ],
    ],
    'limiter'      => [
        'enabled' => true,
        'options' => [
            'interval' => 0.5,
        ],
    ],

    // Cron
    'cron'         => [
        'groups' => [
            'default'     => [
                '/somecommand',
            ],
            'maintenance' => [
                '/cleanup',
                '/sendlogs',
            ],
            'groupx'      => [
                '/commandx',
            ],
        ],
    ],
];

This I meant as a addition to rotator, maybe the user could specify

Ok, this one could be challenging to make "simple". The more possible options/settings, the more complex everything becomes, obviously.

noplanman avatar Apr 20 '17 09:04 noplanman

Definitely loving cron groups idea!

PS. Whoops.

jacklul avatar Apr 20 '17 09:04 jacklul

Oh! Another!

It would be nice to be able to pass own PDO instance with $config array!

Also why we have to use a=set in CLI ? It would make more sense to allow manager.php set which would be much simplier!

jacklul avatar Apr 20 '17 16:04 jacklul

Oh just saw this now:

It would make more sense to allow manager.php set which would be much simplier!

I totally agree with you! The reason why it is as it is at the moment, is that I can use the exact same code to handle CLI input and direct webhook calls. i.e. manager.php?a=set === php manager.php a=set

I know that this will change to what you proposed, but first we should establish base commands and then work on a true CLI app that can be packaged as a phar. This is still quite a bit in the future, but my idea was to be able to manage any bot installation using a general CLI command.

noplanman avatar Apr 25 '17 17:04 noplanman

@jacklul Regarding log rotation, Monolog has a very simple rotator, that rotates daily.

// instead of
(new StreamHandler(__DIR__ . '/debug.log', Logger::DEBUG))->setFormatter(new LineFormatter(null, null, true)),

// we can use the rotator (keeping 5 days of logs in this example)
(new RotatingFileHandler(__DIR__ . '/debug.log', 5, Logger::DEBUG))->setFormatter(new LineFormatter(null, null, true)),

I've been reading online that the best method is to use a dedicated logrotate setup.

noplanman avatar Aug 08 '20 04:08 noplanman

@jacklul Regarding log rotation, Monolog has a very simple rotator, that rotates daily.

// instead of
(new StreamHandler(__DIR__ . '/debug.log', Logger::DEBUG))->setFormatter(new LineFormatter(null, null, true)),

// we can use the rotator (keeping 5 days of logs in this example)
(new RotatingFileHandler(__DIR__ . '/debug.log', 5, Logger::DEBUG))->setFormatter(new LineFormatter(null, null, true)),

I've been reading online that the best method is to use a dedicated logrotate setup.

I agree

jacklul avatar Aug 08 '20 07:08 jacklul

Perhaps this will help someone, I use an even simpler mechanism - I specify the date at the beginning of the file name for easy perception, like this:

(new Monolog\Handler\StreamHandler(__DIR__ . '/logs/' . date('Y-m-d') . '_error.log', Monolog\Logger::ERROR))->setFormatter(new Monolog\Formatter\LineFormatter(null, null, true)),

and using cron (that runs daily), I delete logs older than 10 days

find /path/to/logs/dir/ -mtime +10 -type f -name "*error.log" -delete >/dev/null 2>&1

Leonid74 avatar Aug 08 '20 19:08 Leonid74

Great idea @Leonid74 👍

noplanman avatar Aug 12 '20 15:08 noplanman